Solutions to Name/Object Mapping for Generic Functions

[kempf%hplabsz@hplabs.HP.COM]

Sorry this note has dragged on so long, but the name to object mapping
is a difficult enough problem that I think it requires some thought.

THE PROBLEM AND PROPERTIES OF A GOOD SOLUTION

As my previous note outlined, the problem with making SYMBOL-FUNCTION
sensitive to the environment is that it directly conflicts with the
Common Lisp notion of the symbol's function cell as a global place.
On the other hand, the consequences for CLOS of not somehow making
the metaclass protocol for generic functions sensitive to the environment
are that support for resolving method inheritance at compile time
will not be available in a portable way (it may and probably will be
available in an implementation dependent way, since optimizations
will require it). 

A good solution should somehow avoid either of these extremes. In
addition, the solution should not be such that compilation of a
method causes redefinition of anything funcallable in the compiler's
run time environment, since this could cause bootstrapping to fail.
This particular property rules out, for example, allowing the
symbol's function cell to become like a dynamically bound function
variable.

SOME POSSIBLE SOLUTIONS

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.

Nice properties of each solution are:

1) The existence proof of Scheme and T shows that this solution can be
implemented. It also has a certain elegence.

2) No radical changes in existing Common Lisp implementations would be
needed.

3) No radical changes in the current spec for CLOS would be needed.

Nasty properties of each solution are:

1) Radical changes in existing Common Lisp compilers would be needed.
The issue of a single function/value cell is controversial, this could
be even more so.

2) This would complicate the metaclass protocol for generic functions
considerably. In particular, generic function slot accessors would need
to maintain data structures for mapping environments to methods, and
the dispatch function would need to do the "right" parameter specializer
to method function mapping, namely the one established when the method
was interpreted or loaded.

3) Implementation of object-oriented languages on the metaclass kernel
which resolve method inheritance at run time would have no support.
Optimizations of method lookup would be largely implementation dependent.

I don't like 2 is because it adds additional complexity to
the generic function protocol which I would rather avoid. I actually
like 1 best, but doubt we could ever get it implemented. 
In the interests of wrapping up the loose ends of CLOS as expediently as
possible, I'd like to weigh in in favor of 3. While I think that the
metaclass kernel is an important part of CLOS, most people who want to
use it are more interested in the language for application implementation.
As I hope my previous posting has shown, the CLOS language (or programmer
interface) has no need for maintaining a seperate definition of generic
functions and methods in the compile time environment, since there is
no information about methods and generic functions previously compiled in a
file which needs to be portably transferred from form to form. In addition,
although the lack of this capability made implementation difficult, 
the implementation of CommonObjects on the PCL kernel has shown that
a language which resolves most of method inheritance at compile time
can be done.