Re: a new proposal for environments

[Roberto Ierusalimschy <roberto@...>]

> One subtlety that just dawned on me and I don't think was called out
> previously in the discussion. Under this proposal, all functions in a
> compile unit share the same environment value unless they explicitly
> introduce a new local _ENV variable. This means that the current
> semantics of setfenv cannot be reproduced with the new proposal. Is
> that a misunderstanding on my part? Did I just forget that this point
> was raised? I don't know that this is a "flaw" per se, but it might
> matter to people who use setfenv more aggressively (though since
> setfenv isn't friendly toward re-entrancy or coroutines, I wouldn't
> expect it to be being used aggressively).

This is not a misunderstanding; you are completely right. We are aware
of this. If you want to follow the original semantics, it is still
possible (mostly), but it is not trivial. You should create a new
upvalue (by creating a new dummy closure with one upvalue) and use
the function debug.upvaluejoin to make the _ENV point to this new
upvalue.

You still will have a problem if the function does not have an _ENV
upvalue (that is, it does not use any global variable). In that case,
setfenv could silently do nothing, but getfenv has no value to return.

-- Roberto