Re: _ENV vs _G

[Tim Hill <drtimhill@...>]

On Aug 13, 2014, at 12:17 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.
>>>> 
>>> 
>>> 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.
> 
> Have you read my code in env.lua, verified that it gives the specified
> results, and checked my logic in claiming why it gives those results?
> 
> If not, there is not much point in my trying to argue with you.
> 

Indeed I did, though I was discussing and not arguing. Perhaps we are talking about different things. My reading of your post was that a compiled chunk (which is, by definition, a function) could have any of (a), (b) or (c) as it’s _ENV. My point was that this isn’t true, it can only be (b) or the distinguished environment. If, however, you mean that lexically NESTED functions WITHIN a compiled chunk may have (a), (b) or (c) then yes of course that is true as per the Lua documentation.

As I’m sure we both know, compiling this string:

function foo() end

Does NOT leave the function “foo” on the stack (or, in Lua terms, return the function from load), it leaves a function on the stack that, when executed, will add a closure named foo to the current global environment.

—Tim