Re: Solutions to Name/Object Mapping for Generic Functions

[kempf%hplabsz@hplabs.HP.COM]

>      
>      THE PROBLEM AND PROPERTIES OF A GOOD SOLUTION
>      
>      
>       The following are some possible solutions:
>      
>      1) The symbol function cell could be eliminated as a global object and
>      the name to funcallable object mapping could be maintained within the
>      environment, as is the case in Scheme.
>      
>      2) The generic function slot accessor functions could take an
>      environment argument and return information accordingly. This 
>      was the solution I believe Patrick proposed. 

>      3) We could simply leave it up to implementors to supply these
>      hooks, if they so choose.


> If you are talking about name-to-generic-function mapping, 2 is not what
> I have proposed.  

Yes, you are right. What I should have said is that it is *similar* to
what you proposed. The original proposal mentioned modifying ADD-METHOD,
GET-METHOD, REMOVE-METHOD, FIND-APPLICABLE-METHODS, and
ENSURE-GENERIC-FUNCTION to take environment arguments, which are all part
of the metaclass protocol, in addition to SYMBOL-FUNCTION:

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

I believe the intention was, however, that they should pass the 
environment on to SYMBOL-FUNCTION or use it in some implementation 
dependent manner.

What 2 is proposing is to decouple modification of SYMBOL-FUNCTION to
take an environment parameter, which I believe will have serious
reprecussions for Common Lisp semantics, from the metaclass protocol
modifications. Modification of SYMBOL-FUNCTION would be the essense of
1.

>		 Name-to-generic-function mapping shouldn't depend on
> the metaclass protocol since it should behave the same as
> name-to-regular-function.  

If SYMBOL-FUNCTION is modified to take an environment argument, then
the name-to-regular-function mapping is going to change too. A
metacircular definition of the Common Lisp interpreter might look like;


    (cond

         <other things>

       ( (fboundp (first form))
         (apply (symbol-function (first form)) argument-list)
       )

       <more other things>
    )

Changing SYMBOL-FUNCTION means this becomes;

    (cond

         <other things>

       ( (fboundp (first form))
         (apply (symbol-function (first form) <environment>) argument-list)
       )

        <more other things>
    )

But what environment? The current one? The base one? Modification of
SYMBOL-FUNCTION means that semantics of function application in Common
Lisp must be changed, becoming more like Scheme. Now, I have no objection
to this (in fact, I think it would be an improvement) but some compiler
writers and application developers might. Note that this semantic change
is very different from the one generic functions introduce, because it
involves global (environment) rather than local (parameter classes)
information, and hence could require larger modifications to existing
code.


>		Not being affected by the metaclass protocol,
> it can be left to the implementation.  The hook should be specified
> though.  If some implementations decide to ignore the environment,
> that's fine.  Since the environment is going to be passed explicitly (see 
> Moon's reponse to my proposal), we either need a new primitive for that,
> or change SYMBOL-FUNCTION to accept an environment argument. A new
> primitive for metaclass programmers is probably the best thing to do.

I'm not quite sure what the "or" is here. I understand the proposal for
primitives to access the environment, but I don't understand where
the hook could be, other than through the metaclass method lambda lists.

A way to work around this difficulty might be the following. Instead of
modifying the name to generic function mapping to be sensitive to the
environment, we modify the generic function object to slot value mapping
to use the environment. This was supposed to be the essence of 2. Thus
information on methods being compiled can be stored in the generic function
object, but invocation of the generic function would get definitions
in the compiler's run time environment. This complicates the object to
slot value mapping somewhat, but avoids the problem with changing the
semantics of SYMBOL-FUNCTION. The idea is that the generic function
remembers the environment in which it was defined for funcalling purposes,
and otherwise uses the current environment for maintaining information
about definitions being compiled. Admittedly, this is a halfway solution,
but would involve less drastic modifications to Common Lisp, I think.

> However I object to 3 since it will make serious metaclass programming
> non portable.

It will restrict the class of object-object oriented languages which
can be portably implemented using the metaclass protocol to those which don't
require information on methods being compiled to be portably available
in the compile time environment. Note that CommonObjects is in this class,
and we have gotten around the problems by some monumental kludges and
some portable importabilities, ie., things which each implementor of
PCL needed to customize to their system. That particular part of
CommonObjects on CommonLoops was the most difficult to do, and the
one which breaks most often. The tradeoff for CLOS is that the metaclass
protocol would be simpler, and no modification of the base Common Lisp
semantics would be needed, meaning we could probably converge on a solution
more quickly.