Re: _ENV vs _G

[Tim Hill <drtimhill@...>]

On Aug 12, 2014, at 1:02 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:

> 2014-08-12 19:09 GMT+02:00 Tim Hill <drtimhill@gmail.com>:
>> 
>> On Aug 12, 2014, at 8:48 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> 
>> 4. If you compile a function using `load` or `loadstring`, its _ENV is one
>> of:
>>  a. An _ENV parameter.
>>  b. The _ENV specified in the `load`.
>>  c. An _ENV upvalue.
>> 
>> 
>> I think it’s always either the distinguished environment (the one stored in
>> the registry at a well-known key) or the explicit table specified as an
>> argument to load().
> 
> It's only the one specified in the registry if that still happens to be
> the current upvalue called _ENV. And even the one in the registry
> may not be the one you started with. You can assign something
> to debug.getregistry[2]; not recommended, though.


That’s not my reading of the docs/source, though they are rather unclear.

If you are using load() etc, and you do NOT specify an “env” argument, you will get the distinguished environment (the one in the well-known registry index). Otherwise, the _ENV upvalue of the newly loaded chunk will be set to the specific value supplied by the “env” argument to load(). Any existing value in _ENV in the code calling load(), (regardless of whether it is an upvalue, local, or function argument) is not involved (that is, loaded chunks do not implicitly inherit the environment of the code doing the load()). So, as I said, _ENV for the newly loaded chunk will be either the distinguished environment or an one explicitly supplied as an argument to load().

This certainly appears to be what luaB_load() is doing (the handler for load()).

—Tim