semantics

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

semantics

Luiz Henrique de Figueiredo
>some variation in semantics can be expected as due to
>differences in C compilers.

We make *every* effort that this is not the case!
Our implementation should compile umodified *and* run in the same way in
any platform that has an ANSI C compiler.

>Nevertheless, it would be nice if there were
>some document available, say as for Haskell or ML, which
>laid down some specifications, and it might be a help for
>those coming new to the language.

I think the reference manual does that, but of course it may be incomplete
in that it does not cover all possible cases. Just the other day we were
reading Harbison-Steel about C and they also have "holes"...

>1) In evaluating an expression of the form
>       <exp1>[<exp2>] in an environment <env>
>   which of the following, if any, may I assume?

One way to know the semantics is to see the output of luac -l on the code,
to see what bytecode is generated, and then read lopcodes.h to see what each
opcode does. The semantics of Lua is essentially the semantics of the VM.

For a[b], the result is:

     GETGLOBAL       0       ; a
     GETGLOBAL       1       ; b
     GETTABLE

which means your option (ii). Of course, <env'> is only different from <env>
in this case if there is a "getglobal" tag method in place for the current
value if "a" and this tag method changes the global environment. I think
a "getglobal" tag mehtod should not do this (but a "settable" one might).

More complicated code can change the global environment even without tag
methods. For instance f(a,b)[g(x,y)] generates

     GETGLOBAL       0       ; f
     GETGLOBAL       1       ; a
     GETGLOBAL       2       ; b
     CALL            0 1
     GETGLOBAL       3       ; g
     GETGLOBAL       4       ; x
     GETGLOBAL       5       ; y
     CALL            1 1
     GETTABLE

and so f might have a side effect that affects the value of g, x, and y.

In general, code in Lua is generated from left to right, as it is read from
the source. But you're right the manual does not say anything about order
of evaluation. In any case, you should not write code that depends on this,
although I agree that Lua's semantics may make it hard to do this, if you're
writing complicated code with lots of tag mathods.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: semantics

John Belmonte-2
lhf wrote:
> In general, code in Lua is generated from left to right, as it is read
from
> the source. But you're right the manual does not say anything about order
> of evaluation. In any case, you should not write code that depends on
this,
> although I agree that Lua's semantics may make it hard to do this, if
you're
> writing complicated code with lots of tag mathods.

Are you saying we shouldn't program with side effects?  That is ironic for a
language where variables default to the global scope.

I think any language that allows side effects should be very clear about
evaluation order.

-John



Reply | Threaded
Open this post in threaded view
|

Re: semantics

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>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

Reply | Threaded
Open this post in threaded view
|

Re: semantics

William Leshner
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 <[hidden email]>
> Reply-To: [hidden email]
> Date: Sat, 10 Feb 2001 11:18:09 -0200 (EDT)
> To: Multiple recipients of list <[hidden email]>
> 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
>