Messages as objects

[Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>]

This may be too radical for some of you guys, but I would like to suggest
that messages should be objects [and not just symbols]! 
So far, none of the Lisp-embedded object systems permit this, although fully
object-oriented systems like Smalltalk and Actors do. But it is worth thinking
about making sure this can eventually be done. Here are some reasons 
why [I've got more if anyone wants to discuss it]:

- Implementing "local messages", as Kent suggests, is possible this way, 
without relying on packages, keywords, etc.

- Inheritance can be used for messages, just like objects. The user might
want a message that's "just like the print message, except ..." which clearly
calls for inheritance. This makes a nice duality between messages and 
objects which receive messages.

- Sometimes, the user would like to implement one handler to handle a 
group of related message "keywords", without having to define a separate method
for each keyword. Example: An object might want to say,  "Send all messages
having to do with graphics to the graphics-manager object" where these might
include :DRAW, :ERASE, etc. One would also like to avoid burning in a specific
list of these, possibly having a procedural test as to whether a message was
a graphics message or not.

- Implementing "default behavior" for messages. Often, the behavior of
object systems is extended by introducing new messages to which every object
should have a response. Examples are :PRINT [everything should print], 
:EQUAL [everything should say whether it is equal to something else].
Traditionally, these are done by defining methods on the root of the 
inheritance hierarchy [OBJECT in Smalltalk/Loops, VANILLA-FLAVOR in Flavors]. 

The problem is that as these proliferate, the root becomes a bottleneck,
accumulating large numbers of methods. The obvious solution if messages 
are themselves objects is to give each message object a :DEFAULT method
which can be used to respond if the object does not have an idiosyncratic 
response. If an object does not have a :PRINT method, OBJECT turns around and
sends the :PRINT message a :DEFAULT message to print the object.
This is probably the most important practical reason to allow messages
to be objects.