Re: Names to Objects and Compiler-environment

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

     Date: Tue, 18 Aug 87 20:29 EDT
     From: "David A. Moon" <Moon@scrc-stony-brook.arpa>
     Subject: Names to Objects and Compiler-environment
     
         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? 

Yes, I want to do this primarily because It allows to be more efficient in terms
of structure copy.  My file contains:

(defmethod speed ((thing my-ship))
   .....)
;;some other things but no DEFCLASS for my-ship and 
;;no DEFGENERIC-OPTIONS for speed.

During COMPILE-FILE I think it is unnecessary to copy the generic-function
or/and the class, to hold the method definition.  What I had in mind was to add
the method to the runtime version of SPEED, in another namespace so a lookup for
this method in the runtime environment is not affected.  I realize that we can
avoid this by copying the generic-function object to the compile environment,
but then we will have to copy some other objects (those side effected by the
defmethod) and end up having to copy a large portion of the world.  Since we
tend to store first class object instead of names, we can't get enough leverage
off the name-to-object lookup.  I tried to address this problem.

     And is there any other kind of mapping that they affect?
I don't know, I can't think of any others but I might be ovelooking something.
     
     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.

I agree with you. Passing the &environment argument to get-current-environment
is the best. I feared that the existing implementation would have to change too
much. If we do that, the compiler must tie up their compile-environment to the
macroexpand environment (which, to me, is a good thing ) and therefore must
change. 
I don't think the two environments must be identical: a macroexpand
environment is free to change at each top level form, the compile environment
needs to be stay EQ for the extent of  COMPILE-FILE. I would propose NAMESPACE
instead of environment.??
     
         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 we want a metaclass to be written portably, to use environments, and be able
to implement the searching by itself, GET-METHOD should be able to be coded
like: search the method, using the specified environment as a tag and then using
the next environment and so forth.  Does that make sense?  I guess it is tied to
this assumption: [From my original message: 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.].
     
     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.

I agree. (REMOVE-METHOD gf .... ENV) for example has to store in the place where
the metaclass will search that the method is not to be found in the context of 
ENV. Does this negative inheritance need to be specified?
     
         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?

The problem I see is that the objects are pointed to by more than the
environment: The direct-subclasses slot of a runtime class might point to a
compile-time class.  The environment itself can be hold on to: A metaclass
writer can store object on an Alist whose key is the environment.  I don't think
the garbage collector will be able to get rid of those objects.

Patrick.