lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> The order in which expressions are evaluated should be specified in
> the manual.

Mostly, this is an excellent thing, especially since Lua, unlike C or
FORTRAN, is not aiming for ultimate performance.

> 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.

...and we want to be in the latter camp.

> 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.

Well, if you're going to use imperative languages, this is the sort of thing
you sometimes have to put up with to get good performance! But I agree that
specifying this sort of thing gives much better language semantics, while
not degrading performance much most of the time (and in Lua that shouldn't
matter anyway). However, evaluation order should not (in most cases) be
relied on; it's almost always bad style. Having it fully specified can hide
bugs as much as prevent them.

> 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.

This is a good point.

-- | certain, a.  insufficiently analysed