 |
lua-l archive |
|
|
||
|
On 21 Jun 2006, at 16:52, Mike Pall wrote:
I guess that most developers coming from a C/C++ background have been cautious about relying on a particular argument evaluation order for function calls. Mainly because the C/C++ standards explicitly say this is undefined. But it might be just the opposite when you come from a Java background, which explicitly allows you to rely on a strictly defined evaluation order.
What you say about Java is true, but it seems likely that the intention of the Java maintainers is that different implementations of the Java language (and VM to some extent) are not allowed very much wiggle room. In other words that the same program is executed the same way regardless of the implementation used. It's a kind of unfortunate side-effect that this enables Java programmers to rely on the strictly defined evaluation order. It's not good style to rely on the order, and I doubt many Java programmers could quote the Spec on this matter.
C says something worse than that the order is undefined. In the case of argument lists, for example, updating a given variable (via = or + + say) more than once in the same argument list makes the entire program behaviour undefined.
IIRC Scheme (which, sadly, has side effects) says something like: there is a sequential order of evaluation for arguments, but which one is chosen is not defined (and it's not necessarily even consistent across different runs of the same program or even the same source code function call executed at different times within the same program).
drj