lua-users home
lua-l archive

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

On 22.05.2012 20:28, Pierre-Yves Gérardy wrote:
I mean, why was the syntax (or a variation thereof, since it freed the
% operator) removed?

It is not incompatible with either proper lexical scoping or
read/write upvalues.

It just add syntactic guards and prevents potential blunders

As you can see from the manual, 4.0 syntax didn't guard much if at all, because it also was global-by-default. The current syntax is natural (if it used the word "var" instead of "local", it would be completely natural :) ). If you ask me, I'm sure there's no need to guard accessing upvalues. It's hard to access upvalue instead of local by accident or vise versa. Local-by-default doesn't guard from anything, because when you mistype a variable, it's just treated as another local variable, so the error stays uncaught. The solution to the problem is to use something like 4.0 syntax to access globals, not upvalues.

Here's something I just thought through that can be done in Lua at present and would work good:

In the beginning of script file:
local _G = _ENV or getfenv(1)
local _ = _NOGLOBALS

In code:
function _G.HelloWorld()  end

No access to global variables is allowed after _NOGLOBALS is accessed. Existing scripts wouldn't break, new scripts utilizing this would be checked on compilation, and would also work in stock Lua. Implementation: after chunk compilation do some extra: look through opcodes to find the last usage of _NOGLOBALS global variable and find the first usage of global variable after that. If the both exist, issue an error.

Here's another usage example:
local error = error
local print = print
local _ = _NOGLOBALS

Here all needed functions are stored in upvalues and then direct access to globals is denied. Useful for framework code.

Best regards,
Sergey Rozhenko