lua-users home
lua-l archive

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

>>  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"

_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