[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
- To: email@example.com (Sandra J Loosemore)
- Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
- From: Rob.MacLachlan@WB1.CS.CMU.EDU
- Date: Fri, 20 May 88 18:55:09 EDT
- Cc: firstname.lastname@example.org
- In-reply-to: Your message of Fri, 20 May 88 16:33:47 -0600. <8805202233.AA12692@cs.utah.edu>
From: email@example.com (Sandra J Loosemore)
Date: Fri, 20 May 88 16:33:47 MDT
Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
I guess I'm not sure exactly what I should be more specific about in
this proposal, and how specific you all would like it to be.
This is the "compiler environment" issue. Your proposal allows
implementations to attempt to maintain a separate compiler namespace. This
capability is unnecessary for non-system code, and in the absence of
first-class environments, is too complex and/or vague to reasonably
Saying that the compile-time effect of processing a defining form is
required to be equivalent to that of evaluating it is more specific, and
not compatible with the concept of a compiler pseudo-environment. In my
proposal I do allow that the compiler environment be disjoint from the
environment that compile-file is called in, but the compiler environment
must be a "real" environment.
The fact that systems need some way to protect the running Lisp from
compilation of system definitions is not an argument against flushing the
compiler environment as a Common Lisp concept. Any Lisp system will
provide extensions that aid in bootstrapping the system; kludgey compiler
environment facilities can be enabled by a switch.
Once again, it isn't crucial that this issue be resolved now, since all
reasonable solutions are allowed by your proposal. The only thing I
strongly object to is the treatment of the DEFCONSTANT value form.