[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
- To: firstname.lastname@example.org
- Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
- From: email@example.com (Sandra J Loosemore)
- Date: Tue, 17 May 88 08:39:04 MDT
- Cc: firstname.lastname@example.org
- In-reply-to: Jon L White <email@example.com>, Mon, 16 May 88 23:00:22 PDT
Date: Mon, 16 May 88 23:00:22 PDT
From: Jon L White <firstname.lastname@example.org>
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.
That situation was exactly what this proposal (actually group of
proposals) was trying to get rid of, not re-inforce. The compiler need
not do any "special noticing" of these defining macros at all, because
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. All the compiler needs to recognize is EVAL-WHEN (and the
N ugly package functions). The actions, such as storing macro
definitions, may be (but are not required to be) handled identically in
both the interpreter and the compiler.
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.
The big problem I have with your simplified counterproposal is that few
(if any) implementations already work that way, and I do not believe
that the behavior it specifies is what users really want or expect to