[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
protocols/syntax, semantics of SEND, genericity
- To: CL-Object-Oriented-Programming @ SU-AI
- Subject: protocols/syntax, semantics of SEND, genericity
- From: Kent M Pitman <KMP @ MIT-MC>
- Date: 18 December 1984 18:19-EST
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.
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
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.