"Joerg Beekmann" <jbeekmann.deepcove at telus.net> wrote:
> Are you maintaining that it is expected that the following two snippets are
> not equal?
> | m n temp |
> n := 2.
> m := 3.
> temp := (m := n).
> n := m + temp.
> 
> 
> 

This is an excellent way to get at the situation.  Now add a temp for
the first argument of #+ as well:

| m n |
n := 2.
m := 3.
temp1 := m.
temp2 := (m _ n).
n := temp1 + temp2.

It should be clear what happens now, I think!  (Incidentally, this is
exactly the form I think about Smalltalk with when I do analysis on it
-- break out the subexpressions and give each one its own temporary.  It
seems to be a nice way to think about what's really happening, in this
very imperative programming language we all love.)

To respond to another post, it's pretty normal in programming languages
that the parentheses don't force earlier evaluation.  Instead,
parentheses are normally just used to change the grouping, and the
compiler proper doesn't even *see* the parentheses.

Arguably the status quo is wrong, but is there a *simple* rule about how
to handle evaluation order in the presence of parentheses? 
Left-to-right is a simple rule, but parentheses-first seems harder to
define, especially when blocks get involved.


For what it's worth, the ANSI standard mostly specifies evaluation
order, even though not all languages do.  While I can't find an explicit
statement that the receiver is evaluated before the arguments, section
3.4.5.3 does say that arguments are evaluated left to right.  It doesn't
explicitly mention the receiver, so far as I see, but it seems in the
spirit of the standard that the receiver would come before the
arguments.



-Lex

PS -- ultra-finally, I agree with Bijan -- this code really gags.  My
first impression was "make it go away", and my second was "no, stop the
pain", and my third was "why should I care?"  I'll never write nor (I
hope!) read such code.  Thus, if there's to be any change to the
compiler, let's have it *reject* this code.