Re: issue MACRO-ENVIRONMENT-EXTENT, version 2

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

> This is too vague.  What does "scope of that information" mean?  Dynamic
> scope?  Lexical scope?  You need to say what the *extent* is, not the
> scope.

I agree the wording could use improvement.  The idea is that the extent
of the information is the time during which the processor is processing
the code within that scope.

> An example may clarify my confusion.  :-)  Suppose I'm using
> LOCAL-TYPE-DECLARE as implemented in the writeup (but with
> COPY-ENVIRONMENT added to it, of course), and then I say something
> like:
> 
>   (defun f (x)
>     (local-type-declare ((x fixnum))
>       #'(lambda (y) 
>           (local-type-declare ((y fixnum))
> 	    (+ (typed var x) y)))
>     ))
> 
> Is this legitimate?  Let's assume that the interpreter doesn't do a
> code walk.  The closure returned when you call F has indefinite
> extent, yet it contains a reference to the environment established by
> the lexically enclosing LOCAL-TYPE-DECLARE.  So if this is legal, 
> the environment has to have indefinite extent too.

This wouldn't be any problem when compiled, but you are right that an
interpreter that expands macros during execution would need to use a
macro expansion environment with indefinite extent.  I hadn't thought of
that difference before.  Of course, though, such an implementation would
have to support indefinite-extent macro environments internally in order
to correctly implement closures regardless of the
MACRO-ENVIRONMENT-EXTENT issue, so there shouldn't be any hardship for
it to permit more explicit use of saved environments.  In any case, I
have no objection to saying that local macro definitions have indefinite
extent, it's just the other things that environments might be used for
that worries me.

> Rather than trying to add all these ill-defined qualifications and
> restrictions, if we absolutely cannot agree to give environments
> indefinite extent (or to provide a copier to give them indefinite
> extent), I would much rather see a simple statement that you can't
> assume more than dynamic extent.

Maybe a simpler way to look at it is that you can't expect to be able to
extract from an environment object information that would not be present
(although possibly shadowed) in the environment that would be given to a
macro expander in the current lexical context.  Thus, your example would
be permitted because the saved environment used by the local macro
TYPED-VAR is a lexical ancestor of the environment that the expander is
given directly.  You aren't trying to access a definition that doesn't
exist anymore, just something that might be shadowed in the current
environment.

Similarly, a saved environment could be used to access class definitions
later during COMPILE-FILE, because all environments after that time will
include the same class definitions.

Does that make the concept any clearer?

> > Within COMPILE-FILE, class definitions resulting from a top-level
> > DEFCLASS can not be accessed after processing of the file is complete.
> 
> As far as I've been able to tell, there is nothing in CLOS chapters 1
> & 2 that says that DEFCLASS *must* store class definitions in any
> particular way that involves environment objects.

The problem is with FIND-CLASS, which is documented on page 2-48 to
accept an environment argument:

  "The optional environment argument is the same as the &ENVIRONMENT
   argument to macro expansion functions.  It is typically used to
   distinguish between compile-time and run-time environments."

Perhaps this feature ought to be moved to chapter 3, since it doesn't
help much to have this included in the standard without the supporting
specifications that makes it meaningful.