Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 UW 5/3/83; site uw-june
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!houxm!vax135!cornell!uw-beaver!uw-june!trow
From: trow@uw-june (Jay Trow)
Newsgroups: net.lang.st80
Subject: Re: cascades complaint
Message-ID: <1918@uw-june>
Date: Fri, 26-Oct-84 21:39:20 EST
Article-I.D.: uw-june.1918
Posted: Fri Oct 26 21:39:20 1984
Date-Received: Sun, 28-Oct-84 06:00:53 EST
References: <16722@arizona.UUCP>
Reply-To: Robson@Xerox.arpa
Organization: U of Washington Computer Science
Lines: 60


Forwarded from Smalltalk80Interest^@Xerox.arpa

----------------------------------------------------------------

Date: Wed, 24 Oct 84 14:47:03 PDT
From: Robson@Xerox.arpa
Subject: Cascaded messages
To: arizona!budd@ucbvax.arpa
cc: Smalltalk80Interest^@Xerox.arpa

First the facts:

The expression "3.14159 a b ; c d" is a syntax error.  A cascaded message
expression cannot express the receiver of a message.  This is specified
in the syntax chart inside the back cover of the blue book and is not
contradicted by the brief treatment of cascading in the chapter on expression
syntax.  The only use to which the value of a cascaded message expression
can be put is assignment to a variable (and, for this, it must be the last
cascaded message).  In particular, a cascaded message expression is not a
message expression (perhaps a bad choice of terms); it is an expression.
Expressions cannot, in general, express the receivers of messages unless
they are enclosed in parentheses.

The second expression you mention,
	( 3.14159 a b ; c ) d
is syntactically legal, but your explanation of its meaning is incorrect.
You say "the message d is sent to the result of 3.14159 a b, not to the
result of 3.14159 a b c".  The message d is actually sent to the result
of 3.14159 a c (not 3.14159 a b).  If you wanted the message d sent to the
result of 3.14159 a b c, just leave out the semicolon.  That expression
does, in fact, have exactly the same meaning as 3.14159 a b ; ( c d ), if
I understand the intention of your made-up syntax.  Specifically, the sequence
of messgaes sent in evaluating
	( 3.14159 a b ; c ) d
is:
	(1) send a to 3.14157
	(2) send b to the result of (1) and discard the result
	(3) send c to the result of (1)
	(4) send d to the result of (3), its result is the result
		of the entire expression

Now the opinions:

I have always argued against cascading in the Smalltalk syntax.  I think
that any feature that isn't logically necessary must have significant value
to offset the complication it creates.  I don't feel that this is the case
for cascading.  I think that cascading makes programs harder to read and
that the avoidance of temporary variables is not worth it.  I obviously
lost this argument in the Smalltalk-80 design process.

I hereby appologize for the confusing naming of syntactic entities.  The
fact that a cascaded message expression is not a message expression is
unfortunate at best. 

Dave

----------------------------------------------------------------