[Nickle]Sequencing of expressions with side effects

[Bart Massey]

Naah.  If you're gonna honor the precedence of operators in
expression evaluation, you should also honor the
associativity: assignment operators associate right-to-left,
and should thus evaluate right-to-left.

The claim in the manual that
  (a += b) == (a = a + b)
should be corrected: since we're evaluating right to left,
we want
  (a += b) == (a = b + a)
IMHO this is fine.  Alternatively you could make the
compiler follow the original definition:
  a += b --> a = (int x1 = a) + (int x2 = b);
which would still be consistent with the principles
espoused above.

(We should in any case document += as what it is---a right-associative
operator (evaluated right-to-left)---rather than calling it
syntactic sugar.)

Sorry to break your extremely clever fix, Keith :-).  And
thanks, Carl, for the bug report!

	Bart

In message <E17X2FE-0000bU-00@localhost> you wrote:
> 
> Around 15 o'clock on Jul 23, Carl Worth wrote:
> 
> > 	a = a++;
> > 
> > the behavior of which is undefined.
> > 
> > Do nickle's semantics prevent such undefined behavior? I couldn't find
> > any definition of ++/-- nor any discussion of the sequencing of the
> > side effects of expressions.
> 
> The intent is for the semantics to have well defined behaviour in all 
> cases.  The evaluation order within expressions is controlled by 
> precedence.  Within operators, or within a list of operators of equal 
> precedence, the evaluation is strictly left to right.
> 
> However, the compilation of assignment operators currently violates this
> rule; the right hand side is evaluated before the address of the left hand
> side:
> 
> 	> int[2] a = { 3, 4 };
> 	> int j = 0;
> 	> a[j] = j++;
> 	> a
> 	[2] {3, 0}
> 	>
> 
> Fixing this will be a bit tricky, as the compiler must handle the multiple 
> assignment case:
> 
> 	> b[j] = a[j++] = j++;
> 
> It looks like nickle will need to stack the lvalues until reaching the 
> rvalue and then unwind the stack with multiple stores.  In the case
> of += style operators, the evaluation of the lvalue will be followed by 
> fetching the referenced value before the evaluation of the right hand side.
> 
> I think this is easy.
> 
> Keith Packard        XFree86 Core Team        HP Cambridge Research Lab
> 
> 
> 
> _______________________________________________
> Nickle mailing list
> Nickle@nickle.org
> http://nickle.org/mailman/listinfo/nickle