Compilation implications

[Jon L White <jonl@lucid.com>]

I'll address only the comments you have under item (3).

re:  name equivalence only (i.e. the names of the
    classes are the same) may not be sufficient, because the number and names 
    of slots might be changed, and, in order to FASL the object in, there must
    be at least as many slots as their were when it was FASLed out. Having
    the same slot names is probably also necessary, since it allows a logical
    mapping between the slot contents in the FASL file and the object in 
    memory, as well as the physical constraint of having enough slots to 
    handle the slot contents. 

Well, at load time you could just assuming that a compile-time reference 
to a class named FOO is not inconsistent with the class named FOO existing 
at load time. [I was more worried about forward references in the compiled 
file, that weren't "forward" when the compile-time environment was built -- 
happens e.g. when you load things out of order].

Part of what you are suggesting could be compared, by analogy, to the
package case.  Lucid currently only dumps the name reference; but you
are saying for example that it could also dump the names of all "used" 
packages just as a consistency check.  Unfortunately, I don't see how 
to evaluate the myriads of consistency checks that could conceivable be 
placed in a "dumped" class; would they be worth the effort?


re: In particular, two instances of the same anonymous
    class which are FASLed out then in cannot ever have a class object which 
    is EQ or EQL, since the FASL in code will create two separate instances 
    of the  anonymous class. 

This is not a problem in Lucid Common Lisp [by the bye, I'm assuming a 
single COMPILE-FILE -- I'm not talking about the problem of separate file 
compilations]  LCL file-compilation arranges to preserve EQLness over the 
data objects in a single compile-file.

At one time, some implementations didn't even preserve EQLness over
uninternd gensyms (over a single compile-file); but PCL dependended
so heavily on this working, that those implementations at least made
that case work.


-- JonL --