Goals and Major Design Principles (violent reply)

["Robert W. Kerns" <RWK@SCRC-STONY-BROOK.ARPA>]

    Date: Wed, 31 Oct 1984  18:45 EST
    From: Steven <Handerson%cmu-cs-c.arpa@csnet-relay.arpa>
    Re: defstruct.  Defstruct is single-inheritance; Flavors is multiple.  Very
    different.  There are different tools for different uses.  You don't open a
    paint can with a sharp knife.  It's always possible that someone will invent a
    sharp-knife/paint-can-opener in one, but you don't waste your time trying to
    figure one out.  There are entire catalogs of bogus tools that nobody uses [I
    guess if you buy one, you're apt to buy many].

On the other hand, you could go broke (run out of space, fill up your
bookshelf, confuse yourself) buying lots and lots of single-purpose
tools.  A 2x4 cutter.  An interior-grade-plywood cutter.  A masonite
cutter.  Or you could buy a table saw.

I have found that flavors have replaced about 90% of my usage of
DEFSTRUCT, and I find it difficult to justify much of the remaining
10%.  Instead of writing lots of (MY-STRUCT-FOO STRUCT)'s, I use a
lot of FOO's, and I probably gain as much efficiency from using
instance variables as I give up in calling the methods.  I think
a lot of people think in terms of replacing every (MY-STRUCT-FOO STRUCT)
with a message-pass.  This is not the way you use a message-passing
system!  Much of the code that you used to write "outside" the
DEFSTRUCT you'll write "inside" the object, and access the instance
variables directly.

    Trying to redefine everything to use message passing is a good way to create a
    blob of string that nobody can separate, as well as to slow otherwise fast
    things down.  

I didn't see him say that everything has to use message passing!  It is
quite possible to have objects that you don't manipulate via message
passing, but are still "objects", and also SUPPORT message passing.

For example, I firmly believe the integer 6 should support the
:PRINT-SELF message.  That doesn't mean I believe the + operator should
be implemented using message-passing, at least in the INTEGER+INTEGER
case!  DEFSTRUCT accessors don't have to send messages, either, even if
named-structures are build using instances of some object-system.

		  We have an editor that is more powerful and faster than the Lisp
    Machine's, mostly BECAUSE it was written without Flavors (it's also fairly
    portable). 

This is nonsense!  The Lisp Machine editor was written without flavors
as well, since it was done before flavors!  Even today, for most structures
it doesn't use flavors.  Where it does use them, it doesn't use message
passing for the commonly-accessed instance variables, so it's probably
FASTER than using DEFSTRUCTs, on our system at least.

If you've got a faster editor (faster doing what?), it's either because
you're comparing it against the old LM-2/CADR architecture, or you're
running without a reasonable amount of memory, or because you've done a
truly outstanding job on your Lisp, your editor system.

    We DO need standardization to do things like have the lisp system be able to
    talk to different object systems.  Once we have this, then we can worry about
    defining streams and such.  I'm not sure how possible this is, or even if it's
    especially desirable.  

I think it's possible, and desirable.  I think it's important to
standardize on certain message-passing PROTOCOLS.  This is quite
independent of what object-system you implement.  The stream protocol is
one example; if I have an editor stream, written using flavors, I should
be able to bring it (and flavors) to a system using something else, and
be able to print to my stream.  Similarly, I should be able to take a
pretty-printer that talks to LOOPS-based streams to a flavor-system and
use it there.

I don't think we're ready to try to do any of this yet.  (Nor do we yet
have to agree that it's the right thing).  I think this is way down on
the agenda.