> I don't know what ANSI says, but...
> 
> A cascade is a series of messages sent to the same receiver.
> The receiver that is used is the receiver of the (outermost)
> 	message that precedes the first semicolon.
> 
> Another way of thinking about it is...
> 	r m1; m2; m3; m4
> is essentially equivalent to
> 	x := r.
> 	x m1.
> 	x m2.
> 	x m3
> except that this is not an expression (it's a block body), and there's an extra temp needed here.


How about when non-cascaded messages are interspersed?  I'd love to know
a simple rule.  Here are some example cases:

	a x y; z
	0 x y: 1 ; z
	0 + 3 x y ; z
	0 + 3 x y ; * 3
	0 + 3 x y ; times: 3


Cascades are the only part of Smalltalk syntax that confused me when I
wrote a Smalltalk parser a few years ago.  In fact, I still don't
understand it.  Reading Squeak's parser, it appears that cascades happen
at the location that is most convenient.  :)  Reading the BNF syntax on
the Swiki, handling cascades seems to the main reason it is more than
just a few lines long.

Okay, here's my shot.  First, cascades cannot have a message sent to
them (so, "a b; c + 3" is illegal).  That is, the cascade messages are
"top-level", in a certain sense (probably a sense that's not strictly
correct, but this is English.  I'm allowed.)  Second, the cascade
applies to the message of *lowest priority* just to the left of the
cascade.  That is, if there is a keyword message, then the cascade
applies to the keyword message; otherwise, look for a binary message;
otherwise, use a keyword message.  (There has to be at least *one*
message before you start cascading!)

So here are my guesses on the above:

	(a x) y; z
	(0 x) y: 1; z
	0 + (3 x y) ; z
	0 + (3 x y) ; * 3
	9 + (3 x y) ; times: 3

I guess I could generate some parse trees and check, but already I'm
spending too long reading this exciting mailing list when I should be
doing other things!

Incidentally, ANSI doesn't make this issue obvious, though it might be
in there and I just didn't dig deeply enough.



-Lex