Re: issue MACRO-ENVIRONMENT-EXTENT, version 2

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Fri, 10 Mar 89  11:30:45 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> Proposal MACRO-ENVIRONMENT-EXTENT:EXTENDED-DYNAMIC-WITH-COPIER:
> 
> [...]
> 
> 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.  

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.

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.

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.

> 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.  I think it would be
premature to say anything about this here until the meta-object protocol 
settles down.  Also, we don't have any similar restrictions on DEFMACRO
or whatever.

-Sandra
-------