[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
- To: email@example.com
- Subject: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 21 Sep 88 14:23 EDT
- Cc: Sandra J Loosemore <firstname.lastname@example.org>, Gregor.pa@Xerox.com, email@example.com
- In-reply-to: <8809210430.AA00829@defun.utah.edu>
- Line-fold: No
Date: Tue, 20 Sep 88 22:30:38 MDT
From: firstname.lastname@example.org (Sandra J Loosemore)
> Date: Tue, 20 Sep 88 19:46 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> This function needs a way to tell whether a COMPILE-FILE is in
> progress or not (as does CLOS); I hope that the compiler committee is
> going to propose that the environment argument to macros can be used for
> this purpose.
This is not on our list of pending issues, but feel free to submit a
proposal if you have something specific in mind.
Further examination shows that no proposal is necessary! X3J13 has already
voted to adopt 88-002R into the language, and pages 2-47 and 2-48 of 88-002R
already specify that this exists. However to avoid accusations of sneaking
things into the language behind the committee's back, I'll submit a clarification.
References: 88-002R pages 2-47 and 2-48
Edit history: Version 1, 21-Sep-1988, Moon
It may not be clear to everyone that as of the adoption of 88-002R in June,
there is an additional requirement on the semantics of the environment
argument to macro expander functions.
Clarify that when COMPILE-FILE expands a macro invoked from the code
being compiled, the environment argument to the expander function
contains information that indicates that the macro expansion will be
used in the run-time environment, not in the compile-time environment.
This information is used by the FIND-CLASS and ENSURE-GENERIC-FUNCTION
functions, for example.
Clarify that when interpreted code is executed during COMPILE-FILE (this
might be the body of a macro expansion function, or might be the body of
an EVAL-WHEN COMPILE, or might be an interpreted function called from
one of those places), and a macro invocation in that interpreted code is
expanded, the environment argument to the expander function contains
information that indicates that the macro expansion will be used in the
compile-time environment, not in the run-time environment.
Terminology: The compile-time environment is the Lisp in which the
function COMPILE-FILE was called. The run-time environment is the
Lisp(s) in which the LOAD function will be called to load the file
output by COMPILE-FILE.
A test case cannot be written without using CLOS meta objects or other
extensions to Common Lisp. Here is an example:
(defmacro defclass (name ... &environment e)
`(setf (find-class ',name ',e) ...))
CLOS requires this.
Something resembling this already exists in almost all Common Lisp
implementations for internal use by the compiler. Symbolics Genera
currently uses a special variable instead of the macro expansion
environment, which of course is wrong and produces incorrect
behavior in some cases. I don't know about other implementations.
Cost to Implementors:
The cost of including the information in the environment argument to an
expander function is probably trivial, unless the representation of
macro expansion environments is completely non-extensible. The main
cost is making sure that the information is propagated from
COMPILE-FILE, through the compiler, to all places where the compiler
calls MACROEXPAND or MACROEXPAND-1.
Cost to Users:
Cost of non-adoption:
The proposal was already adopted in June, this is just a clarification
of what it entails.
This clarification should save a few implementors some false steps.
Common Lisp's existing concept of environment seems like the right
mechanism to say things about environments.
The CLOS meta-object facility is probably going to need an addition to
the language, to make SYMBOL-FUNCTION support the environment argument
in the same way that FIND-CLASS and ENSURE-GENERIC-FUNCTION do. However,
since I'm not sure if that's needed, and since that would be an addition
rather than a clarification, I'll ignore it for the moment. Similarly,
it would be a useful to have a predicate that can be applied to a macro
expansion environment and tells you whether it refers to the run-time
environment or the compile-time environment. I'm not proposing that now.
The terms "run-time" and "compile-time" are somewhat confusing. Perhaps
better terms, such as the "deferred environment" and the "immediate
environment" or the "future environment" and the "present environemnt"
could be adopted. In this proposal I have used the terms that became
official when X3J13 voted for 88-002R.