lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 15/07/2019 12.09, Viacheslav Usov wrote:
On Mon, Jul 15, 2019 at 10:55 AM nobody < <>> 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

(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