Names to Objects and Compiler-environment

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 17 Aug 87  16:15:27 CDT
    From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>

I agree with the general thrust of what you're saying, but have some
nits to pick and a question to ask.  I might have more to say on this
topic later.

Question: I had thought that environments referred only to the mapping
from names (Lisp symbols) to objects, but in saying that ADD-METHOD,
GET-METHOD, REMOVE-METHOD, and FIND-APPLICABLE-METHODS (not documented)
need an environment argument, I think you're saying that environments
also affect the mapping from generic-function objects to lists of
method objects.  Is this correct?  And is there any other kind of
mapping that they affect?

An environment of NIL should be defined to be synonymous with the
run-time environment, for programmer convenience.

    One can get an environment by the function GET-CURRENT-ENVIRONMENT.  If
    an implementation supports compile-environment, then a call to
    GET-CURRENT-ENVIRONMENT in the top level loop is not EQL to a call to
    GET-CURRENT-ENVIRONMENT inside a macro expansion while compiling a file.

Does GET-CURRENT-ENVIRONMENT take no arguments?  I believe that the
&environment argument to a macro expander is the only viable way for
the macro expander to know whether the code it's going to return has
its meaning defined in terms of the compile-environment or the run-time
environment.  Thus I believe that the macro expander should pass its
&environment argument to GET-CURRENT-ENVIRONMENT.  To avoid confusion,
we should either declare that these two kinds of environments are
identical, eliminating the need for GET-CURRENT-ENVIRONMENT, or else
we should find a new name for the CLOS kind of environment.

If GET-CURRENT-ENVIRONMENT takes no arguments, then what you have is
some form of dynamic scoping, rather than lexical scoping, and you can
get scoping problems.  Symbolics' implementation, and I believe TI's as
well, currently works this way, using the special variable
SYS:UNDO-DECLARATIONS-FLAG to inform macro expanders on behalf of which
environment they are working.  The genesis of this is historical and
predates lexical scoping.  This causes a number of subtle problems.
CLOS should not make this mistake.

    GET-NEXT-ENVIRONMENT ENVIRONMENT.  This function returns the next
    environment to lookup if any or NIL.  This allows the implementation to
    implement search lists.

I don't understand how adding GET-NEXT-ENVIRONMENT to the documented
interface is related to the issue of search lists.  The implementation
can have those without anything special for them in the interface.

If there is searching, and I think there needs to be if only so the
compile environment can inherit from the run time environment, you need
a negative inheritance mechanism, so that the compile environment can say
such and such a method does not exist in the new version of this program
being compiled, even though it exists in the old version that is being
used to do the compilation.

    How does the implementation signal an object that it has been deleted from the
    compiler environment?

I would prefer that object deallocation be left to the garbage collector.
Are there any problems with that?