What are we talking about?

["David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>]

Perhaps we should be talking about the charter of the object oriented
programming interest group, rather than about details.

I believe that Common Lisp is not a complete programming system in itself, and
was not intended to be.  I believe Common Lisp is a substrate-building tool and
a method for enhancing portability.  It is a language, not a programming system.

My belief is that Common Lisp should not specify a particular method of
object-oriented programming, any more than it should specify a particular
AI knowledge representation system or a particular display terminal.
I believe that the Common Lisp white pages should be augmented with the
necessary facilities to make it possible to write a variety of efficient,
portable, yellow-pages object-oriented programming systems.  Multiple
object-oriented programming systems should be able to coexist simultaneously
in the same Lisp environment.  People building applications should be able
to select whichever object-oriented programming system(s) they prefer
for the particular task; there should be a marketplace of ideas.

The charter of this group should be to specify those white-pages facilities
required for the building of object-oriented programming systems, to see that
they are implemneted in our respective implementations, and to encourage the
production of several object-oriented programming systems.  The first systems to
be implemented should probably be Common Lisp versions of systems such as
Flavors and Loops that are already popular.

What are the criteria for inclusion of some feature in these white-pages
facilities, which might be called the object-oriented programming kernel?
The fundamental criterion is that a feature is included if it is necessary
or desirable for it to be implemented in an implementation-dependent way
rather than a portable way.  The two reasons I can think of for this are
(1) efficiency, and (2) close interaction with implementation-dependent
mechanisms such as function-calling, variable-accessing, or the compiler.

What are the criteria for -not- including some feature in the object-oriented
programming kernel?  Anything that can be implemented in portable Common Lisp
code, even if every implementation of every object-oriented programming system
ends up using the same code, should not be included.  Anything that involves
controversial issues should not be included, because people will not agree
and because it would be wrong (for Common Lisp) to try to force them to agree.
I'm sure it will not be possible to attain a perfect separation between
kernel features and controversial issues, but that is what we should aim for.

To sum up: Mechanisms should be in the kernel.  Policies should be outside.

Howard Cannon wrote an (incomplete) proposal for how to do this two or three
years ago.  It was geared to the kernel features necessary to implement flavors,
but that appears to subsume what most other Lisp-based object-oriented
programming systems require.  Steve Handerson has an implementation on the
PERQ of something resembling this proposal.  These might be good places
to start.  I've had enough experience with both of these to know that it won't
be easy; making these mechanisms both efficient and portable to our wide
range of architectures isn't easy.

By the way, if this is all too vague for you, and you want to hear something
concrete, I'll just mention that Flavors have active values already and have
always had them.