[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
- From: Jon L White <firstname.lastname@example.org>
- Date: Mon, 16 May 88 23:00:22 PDT
- Cc: email@example.com
- In-reply-to: Sandra J Loosemore's message of Mon, 9 May 88 09:54:35 MDT <8805091554.AA22789@cs.utah.edu>
One thing bothers me muchly about this proposal -- it re-inforces the old
MacLisp notion of "specially noticing" certain forms at top level without
evaluating them; in particular the MacLisp Compiler had a separate database
which held macro definitions "noticed" in the file being compiled, but
which hadn't been explicitly evaluated.
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?
The many ways in which things can be "noticed", and the meaning of "notice",
is very opaque.
Instead, I'd prefer the issue to be simply "To Evaluate, or Not to
Evaluate, That Is the Question". In short, every form should fall
into one of four categories:
(1) Function definition, in which case not only is the body compiled
but the compiler is permitted to "remember" certain aspects of
the function, such as argument spectrum for subsequent user-friendly
warning messages, and such as source-code for subsequent INLINEing.
[Macro definitions can come under this clause too; but they could
also be listed both in (1) and (2).]
(2) Explicitly-listed form that is implicitly eval-when(eval compile load);
"implicitly" means, "if the user didn't wrap an eval-when around it,
then the compiler puts the 'implicit' one in;" however, any user
supplied eval-when overrides this implicit behaviour. There is already
a precedent with several of the "Seven Extremely Randoms".
(3) An EVAL-WHEN form; explicit semantics for such toplevel forms will be
forthcoming; anyway, it ought to be obvious.
(4) Any other form not in (1) through (3); such is merely compiled and
"shoved" out into the compiler output file.
Because of the need to treat IN-PACKAGE and possibly other "7 randoms"
this way, I don't think we could every reduce (2) to the null set. I admit
that putting too many functions in it would confuse things (making it
harder to remember just what was there). But for starters, why not
all the DEF... forms you listed in your proposal, except for DEFUN and
DEFVAR (and DEFPARAMETER, which is a trivial variant of DEFVAR). This
would mean every CLtL DEF... form (except for the exceptions) is implicitly
evaluated during compilation; when this is undesirable, the user would have
the burden of explicitly wrapping eval-when (eval load) around the form.
I fear that my simplified proposal is what you initially offered a long
time ago, and were beaten back on. But I offer my support for it now,
if clarifying is what you want to do.
-- JonL --