Issue MACRO-FUNCTION-ENVIRONMENT, Version 1

[Kim A. Barrett <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
progress). 

kab

-----
Issue: 		MACRO-FUNCTION-ENVIRONMENT
References:	Macros, CLtL p.143
		CLOS Ch. 1 & 2
		-- tbd --
Category:	CHANGE
Edit history:	02-Jan-89, Version 1, by kab
Related issues: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
		SYNTACTIC-ENVIRONMENT-ACCESS
Status:		For Internal Discussion

Problem Description:

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

Proposal (MACRO-FUNCTION-ENVIRONMENT:NEW-ARGUMENT)

 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
 run-time environments. 

 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.

Proposal (SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT)

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

Rationale:

 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.

Test Case:

 -- tbd --

Current Practice:

 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.

Benefits:

 -- tbd --  ;I didn't want to write just "Fixes the stated problem."

Aesthetics:

 -- tbd --  ;I didn't want to write just "Removes a problem from the language."

Discussion:

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

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