[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
- To: sandra@cs.utah.edu
- Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
- From: Jon L White <edsel!jonl@labrea.stanford.edu>
- Date: Tue, 17 May 88 22:33:43 PDT
- Cc: cl-compiler@sail.stanford.edu
- In-reply-to: Sandra J Loosemore's message of Tue, 17 May 88 08:39:04 MDT <8805171439.AA24901@cs.utah.edu>
re: That situation was exactly what this proposal (actually group of
proposals) was trying to get rid of, not re-inforce. ...
the model Steve and I have proposed is that the macros expand into
EVAL-WHENs to wrap the actions that should be performed at
compile-time.
Gleeep! I've completly misread the intent of your proposal. I believe
I misread it because the first n paragraphs of your PROPOSAL: section
reads like a problem description. Two things need to be done (so I
think) to clarify this: (1) very early mention that this is what you
want to happen -- that compiler "noticing" is merely reduced to usages
of EVAL-WHEN; (2) be much more specific as to what gets EVALuated at
compile time -- the listing of desirable effects in the "proposal"
section is ok, but not specific enough to believe that they are all
being accomplished via normal EVAL-WHEN(...COMPILE...).
re: What I particularly dislike is the half-supported status of "noticed"
things; why will a macro be expandable by the compiler but not by the
interpreter?
I don't understand this. The compiler must expand all the macros it runs
across, and so must the interpreter.
Well you yourself added the phrase:
The actions, such as storing macro definitions, may be (but are not
required to be) handled identically in both the interpreter and the
compiler.
and it is this uncertainty about "not required to be" -- about the non-
equivalence of EVAL and EVAL-WHEN(...COMPILE...) -- that bothers me.
True, no implementation operates exactly like my simplified counter. But
they are not far from it. Probably most are in accord with it on DEFUN,
DEFVAR, and DEFPARAMETER; and Lucid is in accord also on DEFCONSTANT,
DEFMACRO, and DEFTYPE. Also Lucid is "mostly" in accord on DEFSTRUCT in
that it does exactly the same thing as evaluating the defstruct, but doesn't
actually install anything in the symbol-function cells (i.e., it makes
the TYPE entry, makes compiler macros for the functions etc.).
The hardest "pill" to swallow is to decide to make DEFSTRUCT, DEFMACRO,
and DEFTYPE implicitly eval-when(eval compile load) Actually, the
"simplified counter" doesn't depend on which of the varous forms are
promoted to the "implicit" status and which aren't -- it merely tries to
make a uniform interpretation when interpreting and compileing forms that
affect the compilation process.
-- JonL --