[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Suggestion: names-isolation-statement
- From: nobody <nobody+lua-list@...>
- Date: Mon, 15 Jul 2019 14:50:26 +0200
On 15/07/2019 12.09, Viacheslav Usov wrote:
On Mon, Jul 15, 2019 at 10:55 AM nobody <email@example.com
> What about to-be-defined "globals"? (Will you have to "pre-declare"
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