[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
time of evaluation of defstruct, deftype, etc.
- To: common-lisp@SU-AI.ARPA
- Subject: time of evaluation of defstruct, deftype, etc.
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
- Date: Wed, 15 Jan 86 18:01 EST
- In-reply-to: <FAHLMAN.12175474181.BABYL@C.CS.CMU.EDU>
This problem cannot be solved with multiple address spaces, unless you have a
very complicated mechanism for sharing objects between address spaces, and
cannot be solved with packages, because packages provide partial sharing and
partial isolation with the division between sharing and isolation not being the
same division that you need to distinguish the Lisp world in which you are
running the compiler from the Lisp world that will exist when the compiler's
output is loaded.
A more viable technique is to attack the problem not at the level of binding
objects to addresses, and not at the level of binding strings to symbols, but
at the level of binding names to objects. Many compilers already do this for
macros, using one mechanism for binding the name of a macro to its definition
when DEFMACRO is loaded, or evaluated interactively, and a second mechanism
when DEFMACRO is compiled. It isn't difficult to extend this to other name
bindings, such as binding a structure name to the internal description of the
structure. I'm sure we can all design data representations for doing this.
The main issue in implementing this is getting each place that looks up a name,
looking for an object, to know which mechanism it is supposed to be using. In
some cases the lexical environment Common Lisp passes to macros is an
appropriate place to store this information. I could say more, and so could
other implementors, but I don't want to bore you.
Stepping back a level, the main issue for the Common Lisp community is do
we want to say that this is an issue which each implementation should solve
for itself, in order to have a compiler that can be considered "high quality",
or is this something that should be made a standard part of the language,
with a portable interface? Obviously one alternative is "better" for the
users and the other alternative is less work for the language standardization