🚀 go-pugleaf

>>> On 3 Nov 1995 02:32:11 GMT, Vassili Bykov <vbykov@cam.org> said:

Vassili> piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote:

pcg> The term "message" as in "unary message", "binary message",
pcg> "keyword message" (same page and book as above), is always used to
pcg> denote the message selector plus the arguments, that is a procedure
pcg> call:

pcg> 	receiver messageSelector: messageArgument.
pcg> which is the equivalent of
pcg> 	messageSelector(receiver,messageArgument);

Vassili> And what exactly is your implied semantics of that
Vassili> `selector(receiver,...)'? If by that construct you mean a plain
Vassili> function application (like in C), that is *wrong*.

Dont' be so dense -- I was referring to notational equivalence. A plain
function cannot be, because there is no plain function calling in
Smalltalk. The goal of the pragraph above was to make it obvious that
the 'r m: a' notation is just syntactic sugaring for 'm(r,a)', where 'r'
is just the one argument on which dynamic overload resolution is done.

Vassili> Such syntax transformation would be correct for CLOS, but there
Vassili> `selector' would be a generic function, not a usual one, so it
Vassili> wouldn't work as an illustration that a message send is a
Vassili> "plain" function call anyway.  (Actor also uses a function-like
Vassili> syntax but actually does a runtime method lookep based on the
Vassili> first argument's type).

I never wrote that it is a "plain" (what does that mean?) function call:
my point was precisely that it is just a regular function call with
dynamic overload resolution on one distinguished argument. There is no
reason to invent a special notation and terminology like Smalltalk's,
and indeed Actor is an an example of this.

Vassili> The difference is in runtime lookup, as it was pointed out by
Vassili> David,

I think you are crediting him with a concept that he did not express: he
wrote:

  David> Sending has two steps in Smalltalk:

  David> (1) LOOKUP -- Given a message name (or method name since they are
  David> the same) -- find the one method in the context of the receiver
  David> that has the same name.

  David> (2) INVOCATION -- Start up that method. This part is EXACTLY the
  David> same as calling a procedure.

and it was clear from this that he was claiming that LOOKUP was unique
to Smalltalk, which it is not: LOOKUP is done _both_ statically and
dynamically in a myriad of language, OO or not, the only difference in
in temronology, for some arbitrary reason Smalltalk confuses ideas by
singling out procedure calls with dynamic LOOKUP and calling them
'message send', as if they were not procedure calls with dynamic
overloading.

Vassili> but you didn't get the point:

Oh please: the points that David expressed are that as above LOOKUP is
done only in Smalltalk & similar languages, a ridiculous notion as it is
part (either dynamically or statically) of any call of a named procedure
in any language, and that somehow, because of the (dynamic) LOOKUP:

  David> Sending is a bigger concept that calling; a much bigger
  David> concept. It is what makes OOP special.

which is another ridiculous notion because dynamic LOOKUP is not at at
all special to OO, and is used to much good effect in a myriad languages
based on different paradigms.

My point is that given that all languages do LOOKUP, and many also do it
dynamically, describing procedure calls with dynamic overload resolution
with a special term leads people like you and David into thinking it is
something special and unique to Smalltalk or OO. I think that by now you
and David and others have proven that this is not an imaginary danger...

Vassili> Lookup is done in Smalltalk at runtime and that is *more* than
Vassili> just a difference in implementation, as you try to argue.

I have never said it is just a difference in implementation, indeed I
argued that the implementation (dynamic overload resolution) is exactly
the same in manuy other, even non OO, languages, say Lisp, and
Smalltalk, the only difference being a gratuitous difference in
terminology.

Vassili> [ ... example of dynamic overload resolution ... ]

Vassili> These two calls to "draw" CANNOT be function calls in C
Vassili> sense--with functions to apply determined at compile-time (they
Vassili> can only if implementation (1) below is used).

So what? Was I talking about C? Are you being dense just to waste time
in pointless arguments? Please reread the thread, and you will discover
that to me whether overloading is resolved at runtime or compile is not
that different: inded I think that by default resolution should be at
runtime, with compiletime resolution as an optimization (e.g. as in some
Objective C compilers). There is nothing magic in overload resolution,
whether static or dynamic -- it does garner the same benefit, extended
reuse, and, possibly, genericity, which also obtains further
reusability.

It is something that many languages have, even dynamically, without
being OO. I see no point in confusing innocent people (like you) with
calling 'message sending' the special case in which overloading is
resolved at runtime. Have you any argument as to why:

	(+ (if (> 0.5 (random)) 2 3.0) (if (> 0.5 (random)) 4 1.0))

should be called message sending and 

	(+ 2 4)
	(+ 3.0 1.0)

should not? What's so tragically different?

pcg> But whether the lookup or invocation are done at runtime or compiletime
pcg> does not matter; all languages must first resolve an interface to an
pcg> implementation and then run the implementation. Either can be left to
pcg> runtime, or done at compiletime if possible.