protocols/syntax, semantics of SEND, genericity

[Kent M Pitman <KMP @ MIT-MC>]

I just got caught up on my reading of these object discussions.
I have the following immediate comments on a variety of topics
that have been discussed.

* Protocols

  I strongly agree with the suggestion made earlier that even if a particular
  message passing style (LOOPS vs FLAVORS vs ...) is not standardized upon,
  that at least a syntax should be standardized upon so that users of 
  object systems are not burdened with knowing how those systems were 
  implemented. Some of my other comments will come back to this issue.

* Syntax: SEND should be internal

  Yale Scheme (aka T) has message passing without using the SEND syntax.
  Instead, message sending uses the same syntax as function calling. eg,

   (SEND window :X-POS)       could be written (WINDOW-X-POS window)
   (SEND window :SET-X-POS 3) could be written (SETF (WINDOW-X-POS window) 3)

  This is more abstract since the user can't tell from the call how window
  is implemented.

  This is more flexible since standard utilities like ARGLIST and SETF 
  are naturally appropriate without the addition of special mechanism.

  As an accidental (but fortunate) consequence, people are discouraged from
  "recycling" message names. Lots of objects might want to handle a FOO
  message, but they should all agree that the same abstract operation is 
  being performed. It is common to see LispM programmers recycle names for
  different meanings, and later incidences of (SEND X :FOO) may be confusing
  if you don't know the type of X. In the functional situation, people are
  not as inclined to do this (partially because the compiler does number of
  argument checking, partially because the debugging info associated with
  ARGLIST would get clobbered), so if you see (FOO X), you have a better
  idea what is going on even if you don't know what X is.

* SEND = FUNCALL ?

  I believe it to have been a real mistake that (FUNCALL instance . args)
  is the same as (SEND instance . args) on the LispM. I would like to see
  instances in general not be funcallable.

  The fact that these two are confused means you can't define message 
  handlers for other lisp objects (particularly functions, since
  (SEND #'CAR ':NAME) is otherwise ambiguous with (FUNCALL #'CAR ':NAME),
  which would be an error).

* (SEND non-instance ...)

  I would like to see non-instances be able to handle messages.
  I am not so fussy about whether those messages are extensible; I just
  don't want sending a message to the thing to be an error.

  Mostly I would be happy if they answered only primitive operations like
  OPERATION-HANDLED-P, DESCRIBE, and so on.

* (primitive instance)

  I don't see any reason to make CAR send a CAR message unless we want to
  go the route of changing CL to a pure message-passing language, which
  seems a bit intense.

  Also, there are severe efficiency issues.

  But in any case, someone can always write a MESSAGE-PASSING package
  where MP:CAR called LISP:CAR on primitive lists and otherwise sent a
  message. Anyone that wanted message-passing CAR could shadow CAR with
  MP:CAR, etc. and get the effect at no cost to code that didn't want it.
  The same applies to MP:+, etc.