Names to Objects and Compiler-environment

[Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>]

The name-to-object primitives we have in CLOS are:

Object                Function       Metaclass    Implementation
                                     dependent      dependent

Class                 CLASS-NAME      No               Yes

Generic-function   SYMBOL-FUNCTION    No               Yes

Method              GET-METHOD        Yes               *


Name-to-method mapping implementation should be left to the metaclass writer
since it is tied up to the strategy of finding the applicable methods for method
discrimination and method combination.  Besides name to object mapping, the
implementation provides some generic name services (source filename recording,
redefinition warnings...) that the metaclass wants/needs to use.  This answers
the * sign in the above table.  I believe that we need a portable interface to
those services.

Compile environment: 
In order to avoid side-effecting the running environment during COMPILE-FILE,
the environment stores definitions in another namespace (compile environment).
The management of the environment(s) should be left to the implementation.  All
our name-to-object functions are affected by this.  We could make the
environment implicit and say that those function will return the object from the
"right environment" (SYMBOL-FUNCTION might work like that on some
implementations), but then it becomes hard to write GET-METHOD portably.  I
propose that we make the environment explicit, passed as an argument to
CLASS-NAME, GET-METHOD, their SETF functions and related function such as
FIND-APPLICABLE-METHODS.  I believe that CLOS should not know a whole lot about
environments so we don't require all the implementations currently supporting
compile-environment to change.  Another issue is the dynamic extent of the
compile environment: The implementation control their lifetime.  Their should
be a way for the implementation to signal the fact that a CLOS object no longer
needed because COMPILE-FILE is over.

Proposal(This would be part of the metaclass protocol):

1- Environment:

The implementation should provide some objects called environments.  The
implementation controls their dynamic extent and their representation.
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.

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

The function (GET-RUNTIME-ENVIRONMENT) always
returns the runtime environment.

CLOS will use environment as a key into its data structures to mark an
object defined in a given environment (ie a method defined in a file
during COMPILE-FILE) or to look it up. 

2- CLOS functions that must have an environment argument:

CLASS-NAMED and its SETF form,
ADD-METHOD,
GET-METHOD,
REMOVE-METHOD,
FIND-APPLICABLE-METHODS,
ENSURE-GENERIC-FUNCTION.

Questions:
Do we need to add an environment slot to STANDARD-CLASS, STANDARD-METHOD
and STANDARD-GENERIC-FUNCTION to get the environment they were defined in?

How do we provide a portable interface to those generic "name" services provided
by the implementation?

How does the implementation signal an object that it has been deleted from the
compiler environment?
The following might work but I am not sure:

ADD-TO-ENVIRONMENT OBJECT ENVIRONMENT.  Tells the implementation that
the dynamic extent of OBJECT is the same as the dynamic extent of ENVIRONMENT.

DELETED-FROM-ENVIRONMENT OBJECT ENVIRONMENT this function is called by
the implementation on every object added to the environment by the call
to Add-to-environment before invalidating ENVIRONMENT.  typically, It is
done at the end of COMPILE-FILE.