[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: Compilation implications
- From: jrose@Sun.COM (John Rose)
- Date: Fri, 6 Jan 89 15:19:04 PST
- Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp-Object-System@Sail.Stanford.edu, CL-Compiler@Sail.Stanford.edu
- In-reply-to: Jon L White's message of Fri, 30 Dec 88 03:46:40 PST <8812301146.AA13748@bhopal>
Date: Fri, 30 Dec 88 03:46:40 PST
From: Jon L White <firstname.lastname@example.org>
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 --