Issue: COMPILE-FILE-ENVIRONMENT (Version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 20 Sep 88 22:30:38 MDT
    From: sandra%defun@cs.utah.edu (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.


Issue:         COMPILE-FILE-ENVIRONMENT

References:    88-002R pages 2-47 and 2-48

Category:      CLARIFICATION

Edit history:  Version 1, 21-Sep-1988, Moon

Problem description:

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.

Proposal (COMPILE-FILE-ENVIRONMENT:CLARIFY):
	  
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.

Test Cases/Examples:

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) ...))

Rationale:

CLOS requires this.

Current practice:

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:

None.

Cost of non-adoption:

The proposal was already adopted in June, this is just a clarification
of what it entails.

Benefits:

This clarification should save a few implementors some false steps.

Esthetics:

Common Lisp's existing concept of environment seems like the right
mechanism to say things about environments.

Discussion:

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.