lua-users home
lua-l archive

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


> I was not pleased to see the claims made on pages 22 and 45, that Lua is
> lexically scoped.

I will correct that on page 22. On page 45, as you already quoted, I do not 
say that Lua is lexically scoped, but that it "has a form of proper lexical 
scoping through upvalues". The key point here is that, in a (pure)
functional language, variables do not change values, so semantically there 
is no difference whether I am accessing the variable itself or a copy.
Therefore, I can trivially translate any "program" from Lambda calculus to
Lua (assuming eager evaluation).


> The trick I have seen somewhere in a Scheme implementation is to
> design the bytecode so that it can be easily backpatched in this
> situation.

I thought about that. The problem is to change the design of the 
bytecode... Currently, most instructions have direct access to local 
variables (like any other temporary value). So, it seems that we need 
either to give instructions direct access also to "unlocal" variables (and 
therefore make them more complex and slow), or to generate extra 
instructions to more values between "unlocal" variables and temporaries 
(which involves moving code around, correcting jumps, correcting debug 
information, and other nasty detais...) 

As I said before, I really want lexical scoping in Lua, but programs that 
do not use it should not pay for it. 

An easy solution (but very ugly, I admit) would be to have a different 
declaration for locals that must be accessible by inner functions... 
(Something like "statically_scoped_local x" ;-)

-- Roberto