Goals

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

I guess I'll toss in my thoughts about what we might want to accomplish.

First, there is a lot of demand among potential Common Lisp users for a
Flavor system that is either compatible with the current Lisp Machine
system, or is a slight improvement in ways that the various Lisp Machine
companies will fully support.  Some of these users actually seem to
think that Flavors is the right thing.  Some of them have no idea what
the issues are and are using the term "flavors" generically.  Most,
however, have existing code developed on 3600's that they want to port
to other systems, or plan to move back and forth across this boundary in
the future.  If we don't met this need, we end up splitting the Common
Lisp community into those who use flavors and those who don't, with no
code-sharing between them.

The way flavors are used by Lisp machine people, they have to be quite
efficient, and that means a small amount of low-level,
machine-dependent, non-portable support.  Given this low-level support
in some standard form, it is possible to keep most of the flavor system
code fully portable.  So if we define the portable flavor system in two
parts, each implementation that wants flavors will be able to implement
a very small implementation-dependent kernel, grab the file of portable
public-domain flavor code, and they've got it.

A separate question is whether this standardized flavor-support kernel
should go into the white pages.  Should something be allowed to call
itself a Common Lisp if no flavor system is available, or should we
require this support machinery so that code using flavors is guaranteed
to be portable?  Maybe the issue would go away if we could provide a
file of code that implements the low-level flavor support entirely in
portable Common Lisp.  The resulting flavor system would be slow, and
perhaps not too useful because of that, but it would be legal.
Implementations that wanted a FAST flavor system would have a clear and
finite set of things to improve.

So much for Flavors.  A different but related issue is what a really
good object-oriented system might look like.  I was among those who
opposed including flavors or any other object-oriented system in the
first pass of the Common Lisp definition because I don't think anyone
has got it right yet.  Without going into a lot of flames about what is
wrong with flavors, I think that a lot of people see the flavor system
as being much too complex.  This results from wanting the system to have
completely flexible multiple inheritance, late binding, and still have
everything compiled as tensely as possible.  I think that those are
basically incompatible goals, and if you push a little too hard on them
you get exponential growth in complexity for very little gain.  Maybe
after we've all had as much experience with these things as the Lisp
Machine people, we'll all come around to their point of view; then
again, maybe they're wedged.  In any event, the only way that a
consensus is going to emerge on this is for people to play with a
variety of object-oriented styles, flavors included.  The idea of making
controversial mechansims spend some time in the yellow pages to see if
people like them seems especially appropriate here.

So what can we do?  Some users feel that they need a portable flavor
system, with low-level support that does not give away ANY performance
for generality.  I was hopeful that the same set of non-portable
mechanisms that we need for implementing a portable flavor system would
also be a good substrate for exploration of other object-oriented
systems.  If we can come up with such a common kernel for objects, that
would be the best answer, whether or not we put it in the white pages.
But if this is impossible, maybe we will have to have one very
specialized, very tense kernel for flavors, and a more general kernel
for experimentation with other object-oriented paradigms.

Then again, maybe there's enough horsepower in this group for someone to
come up with an object oriented system that we will all love at first
sight.

-- Scott