[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CLOS
Date: Thu, 13 Aug 87 10:41:02 EDT
From: kgk%cs.brown.edu@RELAY.CS.NET
I have a question about CLOS and I wonder if you could take the time
to respond:
Is it within the CLOS specification for implementations to
1. compile slot access into, e.g., array access, and
2. discriminate generic function calls into the appropriate methods
at compile time,
or does CLOS require these to be compiled into calls to generic
functions? Naturally, I assume that the class(es) of the arguments
are declared at compile time, and that there are no ambiguities (i.e.
via inheritance?) that could not be resolved until run-time.
It's obvious that these optimizations aren't permissible if the classes
or methods involved can be redefined at run time. It's less obvious,
but still true, that these optimizations aren't permissible if new
subclasses and/or new methods can be created at run time. The Common
Lisp type declaration never declares the exact type of an object; it
declares that the object is of that type or some subtype. You can read
`class' for `type' here. The same is true of CLOS method parameter
specializers. Thus at compile time one can never be sure of the exact
class of a value.
However, it has been proposed to add a feature by which the programmer
can declare that nothing will be added or changed at run time, and then
to compile the entire program as a unit. In that case, the compiler
knows the complete set of methods for a generic function and the
complete set of subclasses of a class, and optimizations such as the
ones you suggest would then become permissible. I imagine that by the
time the CLOS specification is finished and approved, there will be a
feature like this in it. Currently, it's not in the document because
the people working out a detailed proposal haven't finished yet.
There is another answer to your question which is also worth repeating.
Note that you have used the ill-defined (in Common Lisp) concepts
"compile" and "compile time". It is certainly permissible for
implementations to make the compiler optimizations you have suggested
provided the user never sees incorrect behavior as a result. One way to
do this is to notice when something has been added or redefined that
makes the optimization impermissible, and automatically recompile the
optimized code so it will work properly in the new environment. Another
way is to compile several copies of a method, each to be used in
different circumstances. For example, one might compile a separate copy
of a method for each subclass of the class used as a parameter
specializer. The CLOS specification doesn't need to discuss these
optimization opportunities, since they are purely implementation issues
(I'm not sure that is actually true; the presence of these optimizations
may turn out to be visible at the metaclass level if we are not
careful.)
- Follow-Ups:
- Re: CLOS
- From: Ken Kahn <Kahn.pa@Xerox.COM>
- References:
- CLOS
- From: kgk%cs.brown.edu@RELAY.CS.NET