[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
- To: cl-cleanup@SAIL.STANFORD.EDU
- Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
- From: Kim A. Barrett <IIM@ECLA.USC.EDU>
- Date: Mon 2 Jan 89 17:31:11-PST
- Cc: iim@ECLA.USC.EDU
Ok, since a volunteer was needed, here goes. I've also included a proposal for
SUBTYPEP, since it has similar problems. There may be other functions that
need this same treatment. CONSTANTP comes to mind, though I've decided to wait
on that until some of the issues regarding DEFCONSTANT settle down. A
VARIABLE-SPECIAL-P predicate would also need this, though that could be handled
right from the start, and can be written portably using the functional
interface defined in SYNTACTIC-ENVIRONMENT-ACCESS (assuming it makes some
References: Macros, CLtL p.143
CLOS Ch. 1 & 2
-- tbd --
Edit history: 02-Jan-89, Version 1, by kab
Related issues: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Status: For Internal Discussion
CLtL is often read to imply that COMPILE-FILE should avoid modifying the
behavior of the running system by changing definitions to correspond to those
in the file being compiled. Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
makes this an explicit requirement, and specifies the kind of side-effects
each of the standard defining forms is required to perform.
Implementing this distinction between the compile-time and run-time
environments requires some mechanism for distinguishing which environment is
being dealt with. MACRO-FUNCTION needs to be able to make this distinction in
order to correctly determine what value to return.
Because CLOS specifies that FIND-CLASS uses an &environment argument to make
this distinction, integration of the type system and the class system requires
that SUBTYPEP also accept an &environment argument, if for no other reason
than to be able to pass it to FIND-CLASS.
Some implementations may have already implemented some parts of these
proposals, but user code which makes use of these changes is currently not
Extend MACRO-FUNCTION to accept an optional second argument. This argument
should be either NIL, the &environment argument received by a macro expander
function, or the environment argument received by an *evalhook* or *applyhook*
function. This argument is used to distinguish between compile-time and
This proposal explicitly does not modify MACRO-FUNCTION to examine the
environment argument for local definitions. MACRO-FUNCTION only returns
a symbol's global macro definition (if present).
SETF of MACRO-FUNCTION is changed such that it only sets the global macro
definition in the specified environment. Thus, if a compiler environment is
specified then the macro definition of the running system is not modified.
Extend SUBTYPEP to accept an optional third argument. This argument should be
either NIL, the &environment argument received by a macro expander function,
or the environment argument received by an *evalhook* or *applyhook* function.
This argument is used to distinguish between compile-time and run-time
CLOS already specifies the use of &environment arguments for the purpose used
here. These proposals make use of that existing facility to fix some other
functions which need the same capabilities.
-- tbd --
Lucid's implementation of MACRO-FUNCTION has an optional second argument for
the &environment. Whether it only returns global expanders or also returns
local (macrolet) is unknown to this author.
IIM Common Lisp generally uses the &environment argument for distinguishing
between compile-time and run-time environments, but for these two functions
(whose arguments were already specified by CLtL) they implement the
discrimination through the use of a special variable.
Cost to Implementors:
These proposals require the compiler environment be distinguishable, but that
seems to already be required by CLOS. Modifying the definitions of
MACRO-FUNCTION and its SETF is probably trivial in most implementations.
Probably the modifications for SUBTYPEP are also trivial. The hard part may
be ensuring that all calls are passing the environment argument, which in most
cases will be a simple word-processing exercise, but in some cases might be
more difficult because the environment has not been passed along to the point
where it is needed.
Cost to Users:
Users must ensure that all calls are passing the proper environment argument,
which entails the same difficulties as for implementors.
-- tbd -- ;I didn't want to write just "Fixes the stated problem."
-- tbd -- ;I didn't want to write just "Removes a problem from the language."
This is yet another case of a fairly widespread problem relating to the
interaction between the compiler and the running system. There seems to be
general agreement that using a special variable to solve this class of
problems is wrong, though several implementations currently use this
technique. The designers of CLOS apparently believe so, and have specified
several of the functions in the CLOS interface as accepting an optional
&environment argument in order to solve the problem of distinguishing between
compile-time and run-time environments. Some members of the compiler
subcommittee also seem to be adopting the use of &environment arguments into
their thinking about how top-level defining forms perform their special
compile-time magic, though with some misgivings.
The decision to not have MACRO-FUNCTION examine the environment argument for
local definitions is based in part on the assumption that the issue
SYNTACTIC-ENVIRONMENT-ACCESS (SEA) will make some progress. MACRO-FUNCTION is
generally used as a predicate or as a place for SETF (the return value is
probably almost never used outside of the implementation of MACROEXPAND), and
SEA proposes a mechanism for determining the presence of a local definition
and for adding local macro definitions to an environment.
SUBTYPEP really needs this change regardless of CLOS, for the same reasons
that MACRO-FUNCTION does. The demands of CLOS simply make it more immediately
The extension of allowing an environment argument from *evalhook* or
*applyhook* functions seems reasonable, though it might be inferable from the
acceptence of &environment arguments. However, since CLtL specifically states
that the &environment argument need not be a complete lexical environment,
this could be arguable. Rather than leaving such a question open for debate,
this proposal makes explicit allowance for such values. If it is agreed that
this explicitness is necessary, then CLOS should ammended appropriately too.