Response to Masinter's multi-slot idea

[Kahn.pa@Xerox.ARPA]

Just before IJCAI Larry Masinter sent out the following message.  I
think its interesting.

I admit this is a wierd idea, and it didn't make it into the paper, but
I like it.

Individual structures have slots, in that each instance of the structure
has storage for each slot declared in its class. One view of a "slot" is
a special kind of method which implements primitive memory (store old
value, return new.)

In CommonLoops, there are multi-methods: methods which are invoked
depending on the classes of more than one argument. Multi-slots are a
logical extension of CommonLoops: memory which is (perhaps dynamically
allocated) for a cross product of instances of classes.

Here is an example:

A "graphics device" is a kind of stream which implements a variety of
operations in addition to the normal stream operations.

A "style" is a user-level description of the way in which character
might get rendered.

For each style and graphics device, there is an independent
specification of how that style can be rendered on the given graphics
device. 

(defstruct (graphics-stream (:include stream)) ...)
(defstruct style)

Now, the odd part is to make "defslot" the inverse of "defstruct":

(defslot (font default-font :allocation dynamic)  
           graphics-stream style) 

which would define

(graphics-stream-style-font <stream> <style>)

as the inverse of 

(setf (graphics-stream-style-font <stream> <style>) <font>)

The dyanamic allocation scheme seems to be the best choice, and could be
implemented via some double-hashing scheme, modulo garbage collector
problems.

In working with CommonLoops it took me a while to get used to the idea
that methods aren't really "owned" by a class.  Is a multi-method
"owned" by the classes it type specifies or does it simply use those
classes?  I believe that a good programming environment for CommonLoops
will allow the user to think about his or her programs as class-oriented
or selector-oriented.  While I still find it hard to think about
multi-slots (the idea that a slot is a part of single object is really
baked into my brain) they may turn out to be important.  There are so
many similarities between slots and methods in conventional
object-oriented programming that I think that if multi-methods turn out
to be important then so will multi-slots.

p.s.  Mark Stefik took extensive notes during the meeting at IJCAI and
we plan to send them out soon.

--ken kahn