🚀 go-pugleaf

>>> On 10 Nov 1995 01:06:46 GMT, Vassili Bykov <vbykov@cam.org> said:

Vassili> pcg@aber.ac.uk (Piercarlo Grandi) wrote:

pcg> The goal of the pragraph above was to make it obvious that the 'r
pcg> m: a' notation is just syntactic sugaring for 'm(r,a)', where 'r'
pcg> is just the one argument on which dynamic overload resolution is
pcg> done.

pcg> There is nothing magic in overload resolution, whether static or
pcg> dynamic -- it does garner the same benefit, extended reuse, and,
pcg> possibly, genericity, which also obtains further reusability.  It
pcg> is something that many languages have, even dynamically, without
pcg> being OO. I see no point in confusing innocent people (like you)
pcg> with calling 'message sending' the special case in which
pcg> overloading is resolved at runtime.

Vassili> You didn't mention this last fact about dynamic resolution
Vassili> before.  Without it, the statement says as much--or as
Vassili> little--as "m(r,a) is just a syntactic sugar for (m r a)", or
Vassili> the other way around.

Since 'm' can well be a name that has to be resolved to an
implementation, it then must be resolved in any way, either statically
or dynamically. I don't have to mention both possibilities every time I
say "procedure call". In many languages resolution can be both static
and dynamic and nobody then calls the dynamic case "message sending".

[ ... the usual list of name->implementation resolution strategies ... ]

Vassili> What relation does each of these strategies have to OO
Vassili> programming--this is an interesting question.  I won't go into
Vassili> discussion of how innocent or confused everybody at
Vassili> comp.lang.smalltalk is--there's a lot of people around here,
Vassili> but what you are probably confusing--at least in your
Vassili> arguments, my apologies if not in your mind--is a model and its
Vassili> implementation:

As we shall shortly see, the distinction is precisely why I think that
calling "message send" a procedure call is such a source of confusion.

Vassili> When we build a model of a system using any of the now abundant
Vassili> object-oriented approaches, we build it of objects "talking",
Vassili> i.e.  sending messages, to each other--because it looks like a
Vassili> Right Thing (tm).[ ... ]

Vassili> All the above verbiage was to say that message passing is,
Vassili> first of all, OO modeling term.  Smalltalk procedure lookup
Vassili> strategy (3) simulates it closer then the other two,

Ans this is precisely, and it has finally come up, and I have been
waiting so long for someobdy to say it, precisely the confusion that I
had in mind when writing:

  pcg> One of the big problems with Smalltalk is the extremely misleading
  pcg> termonology used therein, e.g. 'message' for 'procedure' and
  pcg> 'sending' for 'calling'.

The point is that Smalltalk is indeed used to do modeling, as in
simulation, and there _real_ "message sends" are used, as in between
active threads, and one should not use a terminology that confuses
procedure calls (nested control transfers) with message sends
(asynchronous interprocess communication), both of which are well
established terms.

Now there are basically two dimensions of OO language design: whether it
is class or prototype based, and whether it is procedure or actor based.

Smalltalk is *class* and *procedure* based; unfortunately there are
common misconceptions, among those innocent souls that I mentioned,
which I have tried to clarify in this newsgroup, that instead it is
prototype based or actor based.

It is easy to see why innocent souls have been misled by terminology
into either of the mistakes above: protocols/categories (which many
don't realize being merely a descriptive device, not a linguistic one)
make Smalltalk look like it is a prototype based language (and thus the
inanities about "Smalltalk does not have types"), and Smalltalk used as
a simulation system does indeed look like an actor based language
(except that Smalltalk objects are passive and control transfers are
nested unless one uses the appropriate environment facilities).

But it is a terrible mistake to make the confusion, and a terrible
terminology design mistake to label "message send" what is a "procedure
call", especially when _real_ "message sends" are also used in many
Smalltalk programs.

For if "message send" is used to label procedure calls, then one does
not have a good label for the case where data is (a)synchronously
transferred between threads.


Summarizing, one has _four_ cases (with made up terminology on the
right, in something like Lisp just to make the point that Smalltalk is
not a special case deserving special temrinology):

  (apply (lambda (n) (* n n)) '(2))	; [1] implementation activation

  (sqr 2.0)				; [2] call with static resolution

  (sqr (if (> 0.5 (random)) 2 2.0))	; [3] call with dynamic resolution

  (progn				; [4] "real" message sending
    (send *sqr-actor* '(2))
    (send *sqr-actor* '(2.0))
    (recv *sqr-actor*)
    (recv *sqr-actor*)
  )

Unfortunately the standard Smalltalk terminology is confusing, and
indeed confuses many people, because while [2] and [3] are really
variants on the same technology (of which [1] is part), and [4] is very
different, it labels [3] ad if it were similar to [4] instead of [2]
(and [1]).

Vassili> this is why "message passing" has migrated into Smalltalk
Vassili> terminology as well.

Indeed: and this makes the mistake worse, not better, even if the source
of the confusion is comprehensible.

Vassili> This is, at least, what I mean by "message passing in
Vassili> Smalltalk",

Perhaps you should rewrite this as "message passing among the different
threads that are part of a discrete event simulation written in
Smalltalk".

Or else you should be using not Smalltalk but an actor based language
(not many out there, unfortunately), so that your modeling notion of
"message send" and the language's notion of "message send" are similar
(for, strictly speaking, actor based languages don't have procedure
calls at all, all actor invocations are in way of principle done by
sending messages, even if the syntax looks like a call).

Vassili> and I wholeheartedly agree with you that it is the same good
Vassili> old procedure invocation, just the lookup strategy is
Vassili> different.

Oh no we are back to the dynamic resolution red herring! Why, what's so
different in the lookup strategy between

	Smalltalk	Lisp

	3 + 4		(+ 3 4)
	2.0 + 3.0	(+ 2.0 3.0)