Need for "active" objects, and your STREAM proposal.

[JonL at PARC-MAXC]

Again, risking being "out of step", I'll have to say that I'm a counterexample
to your conjecture in this note:
  "Everyone who has seen this proposal has noticed that it is extremely
   flavor-like. "
In fact, your proposal is a subset of MacLisp's SFAs.  A major deficit of
SFA's is that by having *no* inheritance mechanism,  it's quite difficult
to "get things correct" when you try have a SFA which more-or-less
emulates some system capability, or when you to make a minor extension
of one SFA definition.  Look at the source code for QUERIO to see how bad
it can be (try [MIT-MC]LSPSRC;QUERIO >).

On the other hand, I too share your skepticism about the need for
pervasiveness (or is it "perverseness") of flavors.  Two major thinking
points come to mind:

  1) The NIL design had a much more primitive notion for active "objects",
    under which both smalltalk-like CLASSES and flavors could be built.
    In fact, the MacLisp/NIL system did just that (Dubuque built a flavor
    system over EXTENDs, while co-existing with the CLASS system).  This
    design permitted a default "inheritance" technique (which could trigger
    microcode on machines that have it) but didn't force you to take only one.
    Also, by having the "inheritance" technique vary on a per-class basis, even
    the ACTOR/Hewitt people could be satisfied with it.

    Inheritance techniques are still under active debate and research (The
    upcoming SmallTalk will probably have multiple inheritance even!), so it
    would be a bad idea for CommonLisp to standardize on one of the many
    alternative proposals right now.

  2) Just about anything doable with smalltalk-like classes is (easily) doable
    with flavors; but the question arises "how many things are (easily) doable
    with flavors but *not* doable (reasonably) with lesser facilities?"  One's
    answer may depend on whether or not he views flavors as some kind of
    panacea.  I had always thought that a window system was flavor's strong
    case, but before making up your mind on this point, I suggest you see a
    demonstration of the non-flavor InterLisp-D window system at AAAI.

    According to a bunch of non-Xerox linguists who've used both window
    systems, the user-sensible features of InterLisp-D were preferred; apparently
    the Xerox guys put more energy into developing interesting window ideas
    than in developing Yet-Another-Sort-of-Smalltalk.  This "opinion" comes to
    me secondhand, from a linquistics conference recently, but the sources could
    be tracked down.  I don't think these linguists had an opinion on flavors
    (likely they didn't even understand them),  but probably they were better
    off for the lack of that opinion/knowledge;  after all, they only wanted to
    use the system, not implement it from scratch.