Re: Compilation implications

[kempf@Sun.COM]

A couple comments on the original and Moon's followup.

1) I proposed as a strawman awhile back that a read macro be introduced
similar to #S for DEFSTRUCTSs so that CLOS objects could be stored in
readable ASCII form and also so that they could be made persistent. 
There was some discussion on the issue but it eventually died out without
a proposal.

2) I think Moon's solution of a constructor form which gets executed using
EVAL at load time is the only possible solution to this problem. In particular,
the semantics of quoted constants implied by CLtL is that only symbols can
be expected to be EQ across a FASDUMP, and only characters and numbers can
additionally be expected to be EQL. This has interesting implications 
for EQL specializers. Since the only objects which can be 
expected to survive a FASDUMP and remain EQL are symbols, 
numbers, and characters, these are the
only objects which make sense to have in a DEFMETHOD form with an EQL
specialized parameter. This makes it important that machinery
be available to add methods to a generic function through a functional
interface, since some of the things one wants to do with EQL methods require
other objects. Part of that machinery is already in Chapter 2 
(ADD-METHOD, MAKE-INSTANCE) but part of it is not 
(how to make a method function, for example). 

3) With regard to using name equivalence for classes across FASDUMP, again,
I largely agree with Moon on this issue, however I'll take the liberty of
extending his comment somewhat, since I think that slot structure needs
to be taken into account. The problem is basically one of how to handle
class or type equivalence of two CLOS objects in FASL files. When the
two objects are FASLed back in, when will their classes be the same? 
Because of the restrictions on EQ and EQL, the class objects, themselves,
cannot be FASLed out because they are not guaranteed to be EQL when 
FASLed back in. This solution is impractical in any case, since it implies
FASLing out the entire metaobject structure at compile time just to save
a single object. Also, name equivalence only (i.e. the names of the
classes are the same) may not be sufficient, because the number and names of
slots might be changed, and, in order to FASL the object in, there must
be at least as many slots as their were when it was FASLed out. Having
the same slot names is probably also necessary, since it allows a logical
mapping between the slot contents in the FASL file and the object in memory,
as well as the physical constraint of having enough slots to handle the
slot contents. Note that, again, EQLness of slot descriptor objects, or
any other solution not involving symbols won't work. Requiring the same
class precedence list, or that the inheritance of slots match strikes
me as too restrictive, though I could see arguments why it would be desirable.
Alternatively, the class redefinition protocol could be put to good use to 
allow the object to redefine its class if the number and names of slots didn't
match. In that case, name equivalence of classes is the only requirement.
Note that this solution handles anonymous classes fine, but not instances
of anonymous classes. In particular, two instances of the same anonymous
class which are FASLed out then in cannot ever have a class object which is EQ
or EQL, since the FASL in code will create two separate instances of the 
anonymous class. The only way around this problem is to either change the
semantics of EQ and EQL for CLOS objects or to treat CLOS classes separately
during FASDUMP. Using class and slot name equivalence or just class name
equivalence with the redefinition protocol coming into play when there is
a mismatch between the slot structures seems like an easier solution.

				jak