Re: '_ENV.foo' mandatory for non-local assignment.

[Quae Quack <quae@...>]

2011/1/23 Pierre-Yves Gérardy <pygy79@gmail.com>:
> 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 [1]. 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.
>         ...
>     end
>     function bar ()
>         return upval.b -- shortcut: upval as a pseudotable
>     end
>
> I see on drawback to requiring _ENV.foo for assignement : modules. A naming
> convention could be recommended: '__' as the module table, for example.
> Kind regards,
> -- Pierre-Yves
>
>
> [1] http://lua-users.org/wiki/LocalByDefault

The big objection is having to declare upvalules. You had to do this
in lua4.0; and it was found that the current behavior was much better.