[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: kempf@Sun.COM
- Subject: Compilation implications
- From: jrose@Sun.COM (John Rose)
- Date: Fri, 6 Jan 89 15:39:08 PST
- Cc: firstname.lastname@example.org, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM
- In-reply-to: email@example.com's message of Fri, 30 Dec 88 11:27:27 PST <8812301927.AA09230@suntana.sun.com>
Date: Fri, 30 Dec 88 11:27:27 PST
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?