Re: issue MACRO-ENVIRONMENT-EXTENT, version 2

[David N Gray <Gray@DSG.csc.ti.com>]

I think there are still too many unresolved relationships for this issue to
be ready for voting.  We have talked about using environments for three
different things, each of which has different implementation
considerations that affect the extent:

  1. Macro definitions

	If this were all that environments were used for, then proposal
	MACRO-ENVIRONMENT-EXTENT:INDEFINITE would be fine.

  2. Information about current variable bindings, local functions, type
     declarations, and OPTIMIZE declarations (as in issue
     SYNTACTIC-ENVIRONMENT-ACCESS).

	I don't want to have to support access to this information from a
	saved environment object after the compiler has moved on to a
	different lexical scope.  Proposal
	MACRO-ENVIRONMENT-EXTENT:DYNAMIC would solve that, but is more
	restrictive than it needs to be.

  3. Class definitions.

	For these, we want the extent to end at the conclusion of
	COMPILE-FILE.  Again, proposal MACRO-ENVIRONMENT-EXTENT:DYNAMIC is
	much more restrictive than necessary.

I have been talking here about the semantic meaningfulness of the
environments, but there is an orthogonal issue of data representation.  If
the concern is that the environment could be a stack list which physically
no longer exists outside its dynamic extent, then proposal
MACRO-ENVIRONMENT-EXTENT:DYNAMIC-WITH-COPIER makes sense as a way to copy
the list to the heap.  The copier does not appear to be useful for
addressing the questions of semantic extent above.

How about the following:


Proposal MACRO-ENVIRONMENT-EXTENT:EXTENDED-DYNAMIC-WITH-COPIER:

State that macro environment objects received with the &ENVIRONMENT
argument of a macro function or with a *MACROEXPAND-HOOK* function
have only dynamic extent; the consequences are undefined if they are
referred to outside the dynamic extent of that macro function or hook
function.

Add a new function:

COPY-ENVIRONMENT environment				[function]

This function returns an environment object that is semantically
equivalent to "environment" (which must be an object of the type
received with an &ENVIRONMENT argument to a macro or as an argument to
a *MACROEXPAND-HOOK* function), but which may safely be referred to
outside the dynamic extent of the macro function.  This function is
permitted to return an object that is EQ to its argument if that 
object may be safely used.

The meaningfulness of the copied environment is still subject to the
limitation that it can't be used to access information after the processor
which created the environment (such as a compiler or interpreter) is no
longer processing within the scope of that information.  Thus, the
environment can be used in a macro expansion, since the expansion will be
processed in the same lexical scope.  Declarations, variable bindings, and
local function and macro definitions [assuming passage of proposal
SYNTACTIC-ENVIRONMENT-ACCESS] can not be reliably accessed at a later
time.  Within COMPILE-FILE, class definitions resulting from a top-level
DEFCLASS can not be accessed after processing of the file is complete.

  Rationale:

  This allows implementations to use somewhat more efficient techniques
  for representing environment objects.  For example, the storage could
  be stack-allocated, or environments could be bashed destructively
  instead of always being freshly heap-allocated.

  It also allows programmers to use idioms that rely on using environment
  objects outside of the macro expander, while defining limitations on the
  usable extent of that information.  These semantic limitations provide
  flexibility in how the implementation actually represents environments,
  which is important for minimizing the need to change existing
  implementations.