[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: John Rose <jrose@Sun.COM>
- Subject: Compilation implications
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Sat, 7 Jan 89 00:05 EST
- Cc: kempf@Sun.COM, email@example.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM
- In-reply-to: <8901062339.AA00581@lukasiewicz.sun.com>
Date: Fri, 6 Jan 89 15:39:08 PST
From: jrose@Sun.COM (John Rose)
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.
As I pointed out in an earlier message, translation of parameter specializer
names to parameter specializers occurs at load time, not at compile time.
Thus the available space of EQL specializers is not affected by the behavior
of COMPILE-FILE and LOAD.
Now you understand why CLOS uses (EQL <form>) where CommonLoops used
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.
As far as I know, nothing in CLOS, not even in metaobjects, requires the
ability to dump classes with COMPILE-FILE and load them with LOAD. The
programmer writing a particular MAKE-LOAD-FORM method might indeed
implement the behavior you describe, or some other behavior, for their
particular class, but I don't think the core CLOS language requires
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).
This is chapter 3 (metaobject) business. It's probably just an accident
that a few bits of it leaked into chapter 2.
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?
CLOS is a language, not an implementation. The CLOS language does not
specify the speed of particular operations. That's a matter for
implementations to decide based on their own tradeoffs.