On 8/15/07, Christophe Rhodes <csr21@...> wrote:
> I wonder if this kind of functional interface is the right one,
> actually. Both CLISP and Allegro, I believe, have an additional
> direct slot definition initarg to request a specified location for
> that slot, which has obvious advantages from the point of view of
> bootstrapping and avoiding metacircularities in the regular build.
I can't find anything like that in the ACL docs, and while Clisp docs
have a LOCATOR slot option in the DEFCLASS examples, it's not explained
anywhere. Does anyone have a decent reference?
As for bootstrapping issues, I haven't had any trouble so far. :)
Seriously speaking, I did consider a slot option to set the location or
request sealing a location, but that is error-prone and requires modification
of source, so I don't consider it a good option: if you have a large program
you don't want to grovel all over the source fixing locations once you think
things are stable enough -- and conversely, once you discover that you do
need to change things after all, you don't want to have to edit all your class
definitions to refix the slot locations.
Using a non-standard metaclass also doesn't seem like the right answer:
sealing slot locations provides no new behaviour, just a set of additional
guarantees. While the additional _restrictions_ can be considered new behaviour,
I feel they are incidental. Furthermore, slot location sealing can be orthogonal
from metaclasses, so that non-standard metaclasses can benefit from the same
> Those slots are (in your terminology, I guess) implicitly sealed,
> though I suppose it might be possible to override that sealing by
> introducing another direct slot definition. In any case, I think we
> ignore that prior art at our peril.
Definitely. I just seem to have trouble finding that prior art. :)
> Another piece of prior art is Gerd's approach to inline slot access,
> which is not a property of the class or its slots (a global property)
> but a property of the lexical context: a declaration requests inlining
> slot access, rather than having an all-or-nothing per-slot flag. This
> allows the user to specify inlining in cases where it's not provably
Yes. It's also nicely orthogonal from slot location sealing, and has support
for automatic recompilation of things.
I'm not sure sure about the provably unsafe bit, though: it seems to me
CMUCL will just say "sorry, no can do" if the slot is not at a constant
location in all subclasses.
> (Also, this looks a bit like a metalevel function, so I suspect
> consistency would demand slot definitions rather than slot names.)
> Some thoughts.
Many thanks! Some further thoughts: there is an underlying protocol
here, which I have not yet discussed. Much more tentative then the restrictions
on sealing (which have evolved a bit already), but the SEAL-FOO functions are
only one half of the system.
generic function COMPILE-SLOT-VALUE-USING-CLASS instance-form
slot-name-form class env
Called by the compiler for SLOT-VALUE forms for which a superclass
of the instance argument is known at compile-time.
Must return two values: if the secondary return value is true, the
value is the form to use in place of the SLOT-VALUE form. If the
value is false, the compiler should use a normal call that goes through
Default method returns the results of calling
COMPILE-STANDARD-SLOT-VALUE-USING-CLASS with the same arguments if and only if
the class of CLASS is EQ to either STANDARD-CLASS or
and NIL, NIL otherwise.
Authors of metaobject classes can override this behaviour for their
or use the standard optimizations by calling
Note that the form retuned by this generic function must implement the same
semantics as SLOT-VALUE-USING-CLASS for objects of the given metaclass.
generic function CONSTANT-SLOT-LOCATION-USING-CLASS slot-name class
If all instances of all subclasses of CLASS have an instance allocated slot
identified by SLOT-NAME in constant location, returns it, NIL otherwise.
Standard method calls CONSTANT-STANDARD-SLOT-LOCATION with the same arguments
if and only if the class of CLASS is EQ to either STANDARD-CLASS or
Authors of metaclasses can override this for their own metaclasses.