[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Names to Objects and Compiler-environment
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Re: Names to Objects and Compiler-environment
- From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
- Date: Wed, 19 Aug 87 15:21:01 CDT
- In-reply-to: Msg of Tue, 18 Aug 87 20:29 EDT from "David A. Moon" <Moon@scrc-stony-brook.arpa>
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
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
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
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
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.