Compilation implications

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.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
(QUOTE <object>). 

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

       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.