[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: _ENV vs _G
- From: Sean Conner <sean@...>
- Date: Tue, 12 Aug 2014 13:20:50 -0400
It was thus said that the Great Tim Hill once stated:
>
> On Aug 12, 2014, at 8:11 AM, Steven Degutis <sbdegutis@gmail.com> wrote:
>
> > 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”.
> >
>
>
> Read my earlier post. I don’t think the _ENV_G assignment happens when you
> do a load (after all, this would have the effect of resetting _G after
> every call to load()). My reading is that setting _G happens ONCE only for
> the distinguished environment (when the Lua_State is initialized I
> presume), and never again.
_G is only set if you load the base library into the Lua state, either
with luaopen_base() or luaL_openlibs(). Lua itself does not use _G as far
as I can see (checked both 5.1 and 5.2), and I suspect it's there just for
convenience.
-spc