Re: Isn't load() in 5.2 too naive about _ENV?

[Artur Galyamov <artur-pub@...>]

>>  To properly change environment of Lua function, that function should in general follow "_ENV is first upvalue" protocol. This is only guaranteed for newly compiled chunks, i.e. load() with source string argument, and not for string.dump'ed or other arbitrary chunks. -- Artur
>
> Lua 5.2 has changed the semantic of the "global namespace", there is no longer a dedicated fenv table, but the first upvalue instead.
> the `_ENV' identifier is just the **DEFAULT** lexical name for the "first upvalue", so it is meaningful only at compile time. when a chunk is compiled,
> all access to global names are looked up in the first upvalue, the identifier `_ENV' would just be in the debug data to represent the `name' of
> the first upvalue, which could be totally stripped out.
>
> in fact, you may change this in luaconf.h when you config and build Lua 5.2, or even at runtime from C, see LexState.

I thought so, but _ENV is not always first:

----------------------------------------------------
local a
function test()
    return a, b -- upvalue[1]="a", upvalue[2]="_ENV"
end
----------------------------------------------------

_ENV is to function what default gateway is to network station. In
abstract thinking, there is no _ENV, right. But in field of sandbox
programming, _ENV is  *the* conception. I'm wondering why we lost
control over arbitrary chunk's environment with 5.2.

load(...)-ed text sources are still ok, will use them instead.

-- Artur