[armedbear-devel] Problem with defstruct accessor functions and included structures in combination with conc-names

[Ralf Moeller]

On Aug 7, 2012, at 1:51 PM, Erik Huelsmann <ehuels at gmail.com> wrote:

> Hi Ralf,
> 
> On Fri, Aug 3, 2012 at 3:01 PM, Ralf Moeller <moeller at tu-harburg.de> wrote:
> 
> The following file causes a problem in ABCL (1.1.0-dev-svn-14041) when compiled (!) and loaded.
> 
> 
> Thanks for the report. I've been thinking about it and I think the best solution is even easier to code: when an included DEFSTRUCT already defines the same accessor, we should simply not define it again: the result will be that the accessor checks for structs of type 'A and all of its subtypes will be allowed.

I thought about this, but the problem with my example (repeated here for convenience)

(defstruct a (s1 nil))

(defstruct (b (:include a) (:conc-name foo-)) (s2 nil))

(defstruct (c (:include a) (:conc-name foo-)) (s3 nil))

is that, if we focus on defstruct "c",  it is not the included defstruct "a" which defines foo-s1 but it is defstruct "b", which is not related to "c" at all. Thus, in a naive view, the code that generates "c" has to have a look at all substructs of those which are (directly or indirectly) included into "c" (possibly going up and down in the hierarchy several times). I can hardly imagine that this idea will lead to a stable implementation. So, the code for "b" must somehow store in the management info for defstruct "a" that there is a successor function foo-s1 for a's slot s1 (and the accessor is called foo-s1). This slot accessor is not to be generated again for "c", of course, as you said. The strange thing this is that, in principle, foo-s1 is not applicable to instances of "a", but to instances of "b" and "c" only. Since new sub-structures of "a" (with conc-name foo-) can be defined at any time, the type for the applicable structures used in the implementation of foo-s1 cannot be statically encoded but must be dynamically determined, or the code for foo-s1 could be dynamically adapted for every new sub-defstruct of "a" with conc-name foo-. I tend to believe this is not easy to implement.

Best,
Ralf

> 
> I'll log a ticket to that extent and try to come up with the right change to defstruct.lisp. However, if you can submit a patch to that extent, that'd be most appreciated!
> 
> 
> Thanks again,
> 
> Erik.
>