[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: kempf@Sun.COM
- Subject: Compilation implications
- From: Jon L White <firstname.lastname@example.org>
- Date: Fri, 30 Dec 88 20:07:12 PST
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM
- In-reply-to: kempf@Sun.COM's message of Fri, 30 Dec 88 11:27:27 PST <8812301927.AA09230@suntana.sun.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 --