Re: _ENV vs _G

[Steven Degutis <sbdegutis@...>]

This is getting really confusing. So I figured I'd just look in the
source. Here are the relevant chunks of code:

Apparently _G is set inside luaopen_base:
http://www.lua.org/source/5.2/lbaselib.c.html#luaopen_base

It's just doing <env>._G = <env> where <env> is gotten by lua_pushglobaltable.

Here's the definition of lua_pushglobaltable:
http://www.lua.org/source/5.2/lua.h.html#lua_pushglobaltable

It just does lua_rawgeti(L, LUA_REGISTRYINDEX, LUA_RIDX_GLOBALS).

Pretty straight-forward. For the most part, this is the only instance
of _G in the source-code.

The one other use of _G is in an internal table used by luaL_openlibs:
http://www.lua.org/source/5.2/linit.c.html#loadedlibs

Mystery solved.

-Steven

On Tue, Aug 12, 2014 at 10:48 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2014-08-12 17:11 GMT+02:00 Steven Degutis <sbdegutis@gmail.com>:
>> This is my current understanding of how _G and _ENV work based on my
>> reading of the manual and Pil^3 along with Roberto's response to my
>> first email:
>>
>> When you create a new Lua state, its registry (i.e. the table at
>> LUA_REGISTRYINDEX) contains a special table somewhere which is
>> henceforth known as "the global environment".
>>
>> When you load a new chunk for Lua to execute, something essentially
>> equivalent to the following pseudocode happens:
>>
>>     local _ENV = lua_gettable(L, LUA_REGISTRYINDEX, <global environment's key>)
>>     _ENV._G = _ENV
>>
>> That is, _G is a "global" (i.e. a field on the key _ENV) referring to
>> the initial value of _ENV, which is "the global environment".
>
> I don't agree, but I may wrong.
>
> I think it's like this:
>
> 1. When you create a new Lua state, you have an empty stack and two tables,
> the registry and the global environment. The global environment is empty, no _G
> yet, but it behaves like an upvalue called _ENV, so that all
> references to global
> variables get referred to it. The registry contains two items, [1]
> being the current
> running thread and [2] being a the global environment.
>
> 2. When you call luaL_openlibs, some stuff gets put in the registry.
> Into the global
> environment go all the standard library items, including _G
> initialized to value [2]
> from the registry.
>
> 3. The standalone Lua interpreter does both the above, so you never see
> the intermediate state, but if you write your own host program, you can.
>
> 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.
>
> Note that _ENV is never global. You can assign anything you like to _ENV._ENV,
> it will not be retrieved if you merely say _ENV.
>