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

[GrayFace <sergroj@...>]

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