Re: semantics

[Will Leshner <will@...>]

Scheme, for example, is adamant (I sat through many classes with Dan
Friedman making this point over and over again) that order of evaluation is
and should be undefined.

> From: Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br>
> Reply-To: lua-l@tecgraf.puc-rio.br
> Date: Sat, 10 Feb 2001 11:18:09 -0200 (EDT)
> To: Multiple recipients of list <lua-l@tecgraf.puc-rio.br>
> Subject: Re: semantics
> 
>> Are you saying we shouldn't program with side effects?  That is ironic for a
>> language where variables default to the global scope.
> 
> I'm just saying that if you change global variables in functions or tag
> methods,
> then you should be careful. But that applies to any language, even C. (Let's
> not even mention C++ in this respect.)
> 
>> I think any language that allows side effects should be very clear about
>> evaluation order.
> 
> Any language that has global variables allows these kind of side effects,
> but not even C is clear about evaluation order (it only says it's undefined).
> For instance, in b=a+f(), if a is global and f changes a, then the value of b
> is undefined. Even without global variables there are things like b=a+(a++),
> which C books are careful to say it's undefined.
> 
> Ultimately, the compiler is the only authority for how expressions are
> evaluated. In the case of C, they may give different results, because there
> are many different compilers for many different platforms. In the case of Lua,
> there's only one compiler, which generates code to a fixed virtual machine and
> thus it's easy to guarantee consistency. Of course, this does not avoid the
> need to say something about evaluation order in the manual, but at least when
> in doubt you can always run luac on the code and see how the expressions is
> evaluated.
> 
> On the other hand, if we want other Lua implementations to exist, the manual
> should be more specific. Other implementations might not use the same VM
> (or should they?).
> --lhf
>