Fahlman's mail, syntax and T operations, standard send

[Steven <Handerson@CMU-CS-C.ARPA>]

In response to Fahlman, I feel that most object systems will represent a
small body of code (Flavors sans kernel should be one small to midsize file)
that any CL can run (with the benefit of a kernel), and that there will
typically be only three or four major ones at the most.  Xerox could support
LOOPS, Symbolics would support Flavors, etc.  It shouldn't be hard and
shouldn't cost anything to the users.

In response to KMP's mail:

What do you mean about syntax?  There are a number of ways that the
semantics can change and force the syntax to change - changing the number or
kind of parameters to something, for example.  I've suggested a common
syntax for sends - (send object message-name . message-arguments) - but all
I had to assume (phew) was that all messages have a unique identifying
(atomic) name (like a function name) and some arguments.  I'm not sure how
much you want to assume about how inheritance is done, since if we have
original Flavors AND something else, I would DEMAND that inheritance be done
differently.  Flavors is a complete and utter kludge.  Doing things the same
so that everybody can understand them would have left us in the Dark Ages.

Operations (defined with DEFOPERATION, even in T) can be macros that expand
into a send of the operation name.  An optional send function can be
supplied (to DEFOPERATION) instead of lisp:send, so you can make use of any
macroexpansions or defsubsts of the more specific sending function.

The only problem with the scheme that I've been proposing for a "standard
send" is that it may cost a function call in order to support the various
sending functions.  Still, there could be some way of representing one or more
"standard" sending functions so that no extra function call is made - indeed,
if lisp:send is an instruction, that instruction performs the standard send.
Thus the "standard" thing can be done fast without ruling out the
alternatives.  [See next message.]