Compilation implications

[jrose@Sun.COM (John Rose)]

   Date: Fri, 30 Dec 88 11:27:27 PST
   From: kempf@sun.com


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

  ...

   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

That's only true for non-CLOS types.  I'm quite pleased that Moon's
solution allows the programmer to define new STANDARD-OBJEcT types
which, like symbols, characters, and numbers, preserve EQL-ness across
dumps.  (For example, two Symbolics pathnames are EQL iff they have
equivalent components, thus allowing them to be compared efficiently
and to have well-defined property lists.)  This is done by having
a object being fasloaded into a Lisp "look around" in the Lisp for
a pre-existing "equivalent" object, and, if it's found, return that
pre-existing object's reference.  The definition of "look around"
and "equivalent" is type-dependent, but the technique is general.
(For symbols, "look around" is FIND-SYMBOL and "equivalent" is
"same print name and package".)

You might call any such type an "EQL-preserving" or "interning" type.

So, EQL specializers can usefully apply to symbols, numbers, characters,
and selected STANDARD-OBJECT classes.  Interestingly, STANDARD-CLASS
must be EQL-preserving, since the MAKE-INSTANCE protocol relies on
EQL specializers which point to all the classes.

In my previous message, I argued that mere symbols are not always sufficient
for class names.  In the terms of present message, this means that the
implementation of the interning behavior of classes cannot be simply
"dump the class name symbol, and do a FIND-CLASS when loading".  In fact,
it may be necessary on occasion to create the class on the fly, when
the name is first seen, just as symbols are created when first seen.

   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). 

These are important points too.  But it seems to me that method
definition is essentially an "off-line" activity, like compilation.  Or
do the CLOS people envision fast dispatch __and__ fast generic function
redefinition?  I assume that fast dispatch is being paid for partly by
heavy crunching at generic function definition time.  Or is it all in
the cache action?

  ...
				   jak

					-- John