[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compiler cleanup issues, again
- To: firstname.lastname@example.org
- Subject: Re: Compiler cleanup issues, again
- From: Masinter.pa@Xerox.COM
- Date: 4 Mar 88 09:32 PST
- Cc: email@example.com, firstname.lastname@example.org, mike%acorn@LIVE-OAK.LCS.MIT.EDU, email@example.com
- In-reply-to: firstname.lastname@example.org (Sandra J Loosemore)'s message of Tue, 1 Mar 88 16:15:28 MST
Sandra, I agree with you that if the compiler committee can't revive itself we
should take some more drastic action. Whether the cleanup committee does it or
another, new committee, (e.g., with you as chair), following the same model of
cleanup is less clear to me.
The problem with most of the proposals is that many of them require the
introduction of a new computational model for Common Lisp, with the following
* clear definitions and descriptions of the relationships between read-time,
macro-expansion-time, lexical-analysis-time (compilation), and execution-time
* a clear(er) distinction between top-level and non-top-level
* the semantics of a "file" vs the interactive top level (read-eval-print) loop
* a model for errors which is more fine grained than the current "is an error",
"signals an error" and "must"
* a model for the semantics of declarations
The cleanup committee's proposal format and discussion mechanism isn't well
suited for concept definition. Given an accepted computational model, we can
consider, as cleanups, various changes to Common Lisp to bring things more in
line with that computational model. Perhaps it would help to try to separate out
the concept definition from cleanup proposals.
If previous experience holds, it may be that there will be iterations in the
concept definitions as various cleanup proposals are discussed.
My recollection is that "RAM's compiler proposal" combines both concept
definition and also proposals for changes to the language.