Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.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.

I think we have some confusion here between interpreter versus compiler
on the one hand, and operating in the local Lisp world versus outputting
to a file to be loaded later on the other hand.  I feel that it is
completely inappropriate to add something that distinguishes between
the compiler and the interpreter.  I'd like to see that part of the
proposal dropped.

The important distinction is between what I will call local environments
and remote environments.  A defining form (DEFUN, DEFVAR, DEFCLASS, etc.)
evaluated in a local environment affects the current Lisp world, but in
a remote environment it does not affect the current Lisp world, however
its effects still need to be remembered in a model of the Lisp world
that will be created later.  Both COMPILE-FILE and your example program
annotating program work with remote environments.  I defy you to come up
with an example where the local/remote environment distinction doesn't
make sense and a third type is needed.  Thus I think ENVIRONMENT-TARGET
would better be named ENVIRONMENT-REMOTE-P.


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

Does (setf (gethash a ht) b) mean that b is a part of a?

Again the compiler/interpreter distinction is a red herring and CLOS has
no reason to care about that distinction.  The important distinction
is local/remote.  CLOS needs to know whether a DEFCLASS form changes the
behavior of objects of that class in the current world, or only affects
a future ("remote") world.  Whether this information is "inside" the
environment or "associated with" the environment is a red herring too,
I think; it's a matter of implementation, but has no effect on the
functional interface that the user sees.  I think it's better only to
standardize the one thing that has to be standardized, the local/remote
distinction, and leave the rest (the actual name<->object mapping) to
the discretion of individual implementations.  That way we'll get this
business over with quicker.