Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS

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

> Date: Sun, 2 Oct 88 11:30:37 pdt
> From: Eric Benson <eb@lucid.com>
> 
>  ENVIRONMENT-TARGET env				[Function]
> 
>   This function returns one of the three symbols EVAL, COMPILE or
>   COMPILE-FILE, depending on whether the environment is from the
>   interpreter, the in-core compiler, or the file compiler.  If
>   MACROEXPAND or MACROEXPAND-1 is called directly without supplying
>   the environment argument, the environment passed to any expander
>   functions will have target EVAL.

I really dislike this part of the proposal.  I hate to have to keep
repeating myself, but there are other situations besides the three
listed here in which code may be processed.  The example I've cited
before is a filter that reads in code from a file, performs some
preprocessing to decorate the code with lots of type declarations, and
writes it out to another file.  I contend that anything that needs to
know whether the code is being processed by the interpreter or
compiler ought to be a special form (this includes EVAL-WHEN and
whatever we decide to do about LOAD-TIME-EVAL) and should be left
strictly alone by code walkers.

As to the claim that CLOS needs this information, my understanding
 from reading 88-002R is that what CLOS really needs to store in the
environment is information about the class hierarchy and which
functions are generic functions.  (I'm guessing that the current
implementation does not do this, and instead stores the information
externally to the environment in different places depending on whether
it's for the compiler or interpreter.)

On the whole, I'm rather lukewarm about this proposal.  I hate to add
this much more complexity to the language but I think it's probably
necessary.  When local macro definitions were the only thing that the
environment was used for, you could hack out a code walker by defining
your own representation for environment objects and your own
MACROEXPAND-like function that understands that representation.  I
don't think that's possible any more if we are going to start
requiring that other information (i.e., for CLOS) be stored in the
environment.  Also, you really do need access to proclamations (and
not just SPECIAL proclamations).

A minor quibble:  on all of the functions in this proposal that return 
symbols, how about making them keywords, please?

-Sandra
-------