Specifying expression evaluation order

[ramsdell@... (John D. Ramsdell)]

I enclose more comments on the 4.1-alpha manual.  The first topic on
specifying expression evaluation order is by far the most important.

COMMENT I

The order in which expressions are evaluated should be specified in
the manual.  Specifying this makes it easier to write Lua programs
whose behavior does not change when run on a new implementation of the
Lua language.  In particular, programmers should be able to assume
that:

* expressions in comma separated expression lists are evaluated in
  textual order,

* the function part of a call is evaluated before all arguments,

* in a subscript expression, the table expression is evaluated before
  the index expression, so that in

       expr_1 [ expr_2 ]

  expr_1 is evaluated before expr_2,

* in a table constructor expression, all expressions are evaluated in
  textual order, so that

       { [1] = "first"; "second" }[1] --> "second"
 
  in all implementations,

* binary operations evaluate their arguments in textual order, and
  finally,

* the expressions in the heading of a FOR statement for numbers
  evaluate their expressions in textual order.

On the subject of calls, implementors of languages such as Scheme and
C may choose the order in which arguments are evaluated, while
programmers using languages such as ML and Java can rely on the fact
that all conforming implementations will behave as if a specified
order of evaluation is in effect.

Giving implementors the freedom to change the evaluation order of
arguments leads to funny bugs cropping up when implementors exercise
this freedom.  I had to track down an obscure Scheme bug in my code
that occurred when the implementors of the Scheme compiler of the
system I was using decided to employ a different evaluation order for
arguments than its interpretor.  Debugging this was no fun!  In my
humble opinion, the greatest flaw in the Scheme language standard is
the failure to fully specify function call evaluation order.

For Lua, it is far more critical for programmers to be able to rely on
a specified evaluation order than the previously cited languages.
This is because the meaning of many of its operators can be changed by
through the use of tag methods.  Lua implementors should be required
to trust programmers in that the order in which expressions are
specified correctly communicates the programmer's intentions.

COMMENT II

In the expansion of the FOR loops in section 5.3.4, block should be
enclosed in a DO END pair, otherwise, it implies that final statement
in a for block cannot be a RETURN or a BREAK statement.

COMMENT III

The LALR(1) grammar I gave previously can be made easier to read by
rewriting the var production as follows:

var     --> name
         |  primary index
         |  var index
         |  call index

index   --> '[' expr ']' | '.' key

John