Compiling iv references efficiently, making CL object-oriented

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

Recompiling methods could be tricky.  You don't want the lisp code for every
method hanging around- I doubt any system wastes space that freely.  What might
work is to have the method code segmented and analyzed so that the system knows
what it needs to load and compile in order to recompile the method.  This still
loses if any method was defined at runtime and closed over anything.  This is
almost what I meant by "object system" - that a given approach may imply things
beyond just a set of forms.  This particular system might imply such code
analysis and no runtime definition of methods.

Actually, this isn't so silly as it might sound.  Who's going to compile their
code inefficiently, just so some Joe Schmoe can define his own form of cons?
Who can say with assurance that you'd never want to do such a thing?  This sort
of thing allows the system (in the extreme form) to recompile parts of itself
to satisfy everyone.  This is hard to do, though, and would substantial
rewriting. 

Less extreme: I think microcoded systems could (in theory) easily change
primitive functions like CAR to first see if the object was the appropriate
lisp primitive (which they probably check already) and if not, to see if it's
an instance masquerading as a lisp primitive, and send a message if so.  Other
functions (like sort) might first see if the object responded to the LISP:SORT
message, and if so send it, but otherwise go ahead with its code and have the
primitives send messages.  The test would cost very little; the work would be
harder to justify.  The advantage is that there is one copy of code, which
either does normal lispy things or sends messages (depending), all fairly
efficiently, and nobody needs to treat any code specially.

Side note: this is why I'm for the SEND syntax in general, since you can use a
name for both an operation and a function.  In the case where the basic
operation is the function, why make up another name?  

What other messages should an operation respond to?  Why not just write
(SEND 'operation 'default-fn-name object ...)
perhaps packaged into a macro for you generic-function fans?

Clarification of a previous idea:

A good middle ground is to have the send microcode (if any) identify the method
as a SET or GET method, and do it in microcode.  [To do the SET in microcode,
you need to have the new value, which implies a system that pushes the args and
then invokes a function, like a LispM, and unlike a Perq.  The Perq would also
need something that told the call-frame-building microcode not to do anything.]
This way the system can redefine the message as a real message and we don't
have to recompile anything, and we save a function call over doing it like
other messages.  Of course, this still costs a hashtable reference over doing
it the old-fashioned way, but you wouldn't have to do everything this way.