Various thoughts and opinions

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

The only reason we would want to standardize *anything* is if Common Lisp has
to talk to an object system, as is the case with CAR of an object.  We don't
even have a kernel for Flavors yet, so I don't think there's much point in
discussing a general kernel.  Assuming the kernels are well-designed and easy
to implement, it won't kill to have two or three.  There's not really much
point in standardizing send if you don't get any primitives out of it.

If the sending operation is a macro or defsubst or something, it can look at
the send to see if the operation is a constant (for inline expansion or
whatever).  One of the major differences between send and a function call is
that the operation can be a computed quantity.  Is that what you meant by
quoting the selector?

If we don't standardize sending, then we shouldn't standardize how to send to
non-instances.  We could make up a list of suggested operation names and
arguments, though.  Some are obvious, like 'LISP:CAR and 'LISP:PRINT, but more
complicated operations might be a problem.  I haven't thought about this too
much.

I feel pretty strongly that if you know something is a list, you should use CL
functions instead of sending messages.  Code analysis tools (like compilers)
will then know what you're talking about.  On the other hand, changing the
behavior of lisp primitives is something entirely different and possibly very
fruitful.  This would allow you to (fairly efficiently) use the same operation
(lisp functions and functions written with them) for instances and
non-instances.  Still, you want to do the "normal" thing fast, and then have
exception handling for the unusual thing, not vice-versa.

If each instance has an object-system-name as part of its known structure, and
if we associate a sending function (with agreed-upon arguments) with each
object-system-name, then CL primitives could simply find the appropriate
sending function and invoke it.  The arguments would probably be something like
(object operation-name . arguments), where the operation-names are
standardized.  Flavors (and LOOPS, I think) should be able to just put their
sending functions in as the interface.  Since there are going to be a finite
number of known operations, the sending function could itself do the
dispatching if necessary.  These operations probably want their own package.

Typing such objects is a problem, one I'm not really qualified to talk about.
Presumably you want the system to use typep wherever possible, so that the
object can decide if it wants to be a cons or not.  Typep for "simple" types
could and should be fast, but for objects it should send a message using the
above interface.

-- Steve