Re: Suggestion: names-isolation-statement

[nobody <nobody+lua-list@...>]

On 15/07/2019 12.09, Viacheslav Usov wrote:
> On Mon, Jul 15, 2019 at 10:55 AM nobody <nobody+lua-list@afra-berlin.de 
> <mailto:nobody%2Blua-list@afra-berlin.de>> wrote:
>
> > What about to-be-defined "globals"?  (Will you have to "pre-declare" 
> them?)
>
> Globals are not defined and not declared in Lua. They always exist, with 
> nil values unless assigned something else. Which is precisely why they 
> are a problem.

(By "pre-declare" I meant doing stuff like you need for `strict.lua` or
other checks – explicitly `rawset` the variable or initialize it to e.g.
`false` before using it or something like that…)

What I was trying to get at is that if you say `with x do … end` and x
is not a local variable or upvalue, how do you do the check that

> > > The white-list must contain only visible names, otherwise a
> > > compilation error is raised.
?  Is any global variable (including one that's `nil`) acceptable?
(Then all names are always visible & this condition is vacuously true,
so this doesn't get you any compile-time check at all.)

Otherwise, what is the condition for a global variable to be treated as
"visible"?

(The more I think about this, the more I'm convinced that this cannot
possibly work in any way that deserves to be called "working" – the
parser cannot possibly get that information.  A variable may be set in a
different file, before or after parsing this file, made visible via
__index; the environment may change when/after parsing or during
execution, the environment's metatable may change, etc.…)

>  > Because _ENV can change dynamically, you cannot determine at compile 
> time what names will be valid
>
> Regardless of the proposal, the compiler knows statically what names are 
> global names; those names will be statically converted to _ENV.names. 
> The run-time value of _ENV of irrelevant, the proposal is about 
> statically permitted names.

It only knows what variables are (not) locals/upvalues, everything else
is treated as global / coming from the environment by default.

If you use the same mechanism, that means that `with` again allows
arbitrary undefined variables, so it doesn't really improve the
situation much w.r.t. accidental globals.

>  > What exactly is gained over the current possibilities of _ENV?
>
> A. Static (compile-time) guarantees.

As re-iterated above, I don't see that's possible.

> B. Usability. I am not sure you will easily agree, but the _ENV 
> gyrations in your post are magic incantations to a typical Lua user.

Sure, that's fairly high-magic code – but it could just be what the new
`module` function (if there ever is one again) does internally, and then
you don't have to see this or care about it.  In the simplest non-magic
case, all you say is

  _ENV = module( ... )

and you're set up.  If `module` is allowed to use some debug magic
internally, it could set the loading file's newest _ENV variable and
then you'd have the good old

  module( ... )

with no user-facing mention of _ENV at all.  (Only that you can't
accidentally set globals anymore, you'll have to explicitly prefix with
_G now.)

-- nobody