Re: a new proposal for environments

[Patrick Donnelly <batrick@...>]

On Thu, Feb 25, 2010 at 12:56 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> On Wed, Feb 24, 2010 at 6:38 PM, Roberto Ierusalimschy
>> <roberto@inf.puc-rio.br> wrote:
>> > * Environments for C functions should go too. Actually, they were
>> > introduced only to match environments in Lua functions. The old
>> > technique of setting a table as a common upvalue for all functions
>> > of a library (as done in Lua 5.0) is quite satisfying. (So, the
>> > only "environments" left are for userdata, which probably should
>> > get a more proper name.)
>>
>> Can we still keep the convenience of C environments even if it is now
>> an upvalue. Some support for an equivalent system would be nice even
>> if the implementation is different.
>
> To use the C environment you only change LUA_ENVIRONINDEX to
> lua_upvalueindex(1). To create a group of functions sharing an
> "environment", we may reintroduce something along the lines of
> luaI_openlib (still in 5.1 to keep compatibility with 5.0): It opens a
> C library with all functions sharing a common number of upvalues. (Or
> maybe something more specific.)
>
> Do you have anything else in mind?

I was thinking something along the lines of all C functions having a
special upvalue that is their environment (in the same way as a Lua
function). I guess we could say it is index 0 and that new closures
inherit the environment (upvalue 0) of the creator. (This is currently
how it will work in Lua 5.2 minus the lexical scoping.) The
LUA_ENVIRONINDEX would then be:

#define LUA_ENVIRONINDEX  lua_upvalueindex(0)

Now C functions can index the "magic" _ENV local/upvalue in the same
way a Lua function can.

-- 
- Patrick Donnelly