Compilation implications

[jrose@Sun.COM (John Rose)]

   Date: Fri, 30 Dec 88 03:46:40 PST
   From: Jon L White <jonl@lucid.com>

   Thanks for your many comments, Dave.  I'm sure they will be useful.

   re: ["Reconstructor" forms and mixins]
       I don't remember why the CLOS committee didn't put anything like this
       into the proposed standard.  Maybe we thought it was the Compiler
       committee's business, maybe we had some disagreement, or maybe we
       just ran out of time.

   There is a blend of problems here -- partly object-oriented and partly
   semantics of compilation.  It could be that the buck is getting shuffled
   back and forth and nothing being done.  Maybe the time just wasn't ripe
   for specifying this protocol -- maybe more experience is needed --  but
   sooner or later the user-community will be "push coming to shove" and 
   the lack of a portable interface could be damaging.


   re: [fasling out classes "by name"]
       I don't see how any other way could work, actually, since two distinct 
       compiled files that refer to a class by the same name must end up 
       referring to the same metaobject after loading.  

   Right.  Separate compilation seems to be the clinching argument.

Wait.  Fasling out classes by name is not always the right thing
to do, and any institutionalization of JonL's and Moon's comments
will probably be a mistake.

In recent proposals, fasl-ing out of classes is not specially addressed
by the proposed STANDARD-OBJECT fasdumping protocol, so it's not so
important that we get this ironed out immediately.  Still, I think the
following points need to be made:

1. If anything like a "mixin manager" is being used to create classes
   on the fly, such classes should be dumped not as names, but as
   mixture specifications, perhaps lists of names.

2. In general, dynamic class creation may result in classes which
   are nameless, have gensyms for names, or have names which do not
   fully reflect their nature (such as the mixins of #1).  Yet such
   classes may well have a sensible meaning which is independent
   of the current Lisp instance, and which can be transported across
   load boundaries; such classes need a way to encode this meaning
   in a non-symbol form.

2a. An interesting example of dynamic class creation which shows up less
    in dynamically typed languages is the construction of parametrized
    types.  After instantiating a PT, you compile its methods (or
    whatever you call the code is associated with it) with formal type
    parameters filled in with actuals.  This means that the methods can
    be efficiently compiled for the PT instantiation, using any extra
    information that the actual type parameters give.  For example,
    "stack of character" can use character arrays internally, while
    "stack of bit" can use bit arrays.  These considerations apply
    to any language with PTs.  Some languages can't even begin to
    compile a PT unless it's fully instantiated.

    In Lisp, you can program generic stacks using T-arrays, but at a
    loss of storage efficiency if you're going to use them for bits.
    One solution is to supply a FOO-STACK type for every
    implementationally significant sequence element type FOO.  A better
    solution is to define a class-valued function which takes the
    element type as a parameter, and finds or creates a CLOS class with
    the appropriate efficient code and data structures.  So PTs can have
    a place in CLOS, and give another example where symbols don't work
    well as class names.

    Even better than a class-valued function would be the ability to
    give parameters to class names, just as DEFTYPE names accept
    parameters.  I hope the Meta Object Protocol can be used to do
    this.  In that case, something like '(STACK CHARACTER) might
    make a good fasdumpable class name.

3. This point is concerned less with fasloading from files, but shows
   another way that simple symbols are insufficient to refer to classes.

   An acid test of an object-oriented system is whether objects of
   new classes can be introduced into a running system without breaking it,
   and can take participate in existing protocols.  Often, such
   objects of new class are introduced by loading new modules into
   Lisp, so we can assume that whenever an object is loaded, its class
   is loaded too.

   But what if an object enters a Lisp system alone, perhaps in the
   process of IPC, or from an OODB, and it has a class not seen before?
   It may then be desirable not only for the class to have a name, but
   some indication of where its definition is to be sought, so that it
   may be loaded.  Such autoloading of classes would be necessary in
   systems featuring transfer of objects between Lisps and a large or
   growing space of classes.

So, be careful!  Mere symbols make good class names only for systems of
limited size, and a fixed class population.

   -- JonL --

				-- John