[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: '_ENV.foo' mandatory for non-local assignment.
- From: Pierre-Yves Gérardy <pygy79@...>
- Date: Sun, 23 Jan 2011 01:29:05 +0100
There has already been a lot of discussion regarding the default variable scope, but I don't think that this idea has been proposed.
The new _ENV system enables a way to consistently define non-locals (hereafter globals) without introducing a 'global' keyword.
It is a bit clunky, but since using globals is most of the time a bad practice, making them stand out isn't a problem IMO.
Reading globals would remain the same.
This would allow to remove the 'local' keyword (I know, it's controversial, I've read the wiki page . I will address the technical aspects discussed there).
Introducing explicit upvalues would allow the same scoping flexibilty as the current system, with added clarty.
This should speed up the compiler a bit, since it wouln't have to check whether a variable not declared in a given scope is a global or an upvalue. It would also allow to throw a compile time error if an upvalue isn't found.
You could still declare locals when needed by assigning 'nil' to them.
Here are some suggestions for the syntax.
a,b = nil -- declare the locals at the top of the main block. Only one nil is needed for the list.
function foo ()
upval a, b = 5, 6 -- upval as keyword. Compile time error if they are not found.
function bar ()
return upval.b -- shortcut: upval as a pseudotable
I see on drawback to requiring _ENV.foo for assignement : modules. A naming convention could be recommended: '__' as the module table, for example.