[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Need for "active" objects, and your STREAM proposal.
- To: Scott E. Fahlman <Fahlman at Cmu-20c>
- Subject: Need for "active" objects, and your STREAM proposal.
- From: JonL at PARC-MAXC
- Date: Tue, 10 Aug 1982 09:50:00 -0000
- Cc: Common-Lisp at SU-AI
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
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.