Re: No-globals patch proposal. (Was: Re: Another take on locals by default)

[Xavier Wang <weasley.wx@...>]

2012/5/27 GrayFace <sergroj@mail.ru>:
> 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.
>
> (PROPOSAL)
> 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:
> _G.error()
> _G.print()
> function _G.HelloWorld()  end
> etc.
>
> 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                 mailto:sergroj@mail.ru
>
>

Maybe you can do this by simply:

local _ENV

after this point, all global access are not allowed.

Roberto use this in his re module. (in lpeg)