[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: semantics
- From: Luiz Henrique de Figueiredo <lhf@...>
- Date: Fri, 9 Feb 2001 09:07:31 -0200 (EDT)
>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