On 13/06/2011 21.59, Roberto Ierusalimschy wrote:
Nothing wrong since the discovery of setfenv/getfenv replacements by Sergei Rhozenko, but I remember lhf stating something that those tricks would work only if debug info is present. I don't know very much about the internals of Lua, so I don't know whether missing debug info is usual or in which case it happens (BTW, I was about to ask this). Since this "setting env for a function" seems not too rare (both for efficiency reasons - as Patrick said - or for coping with DSL parsing, as in my usual case), I wonder whether It could be useful to provide a library function such as runin(env, func) that will run func in the provided environment (and maybe this could also bypass the limitation that debug info should be present, removing a source of indeterminacy when using Sergei's replacements). Probably this could cope with most of the complaints of a missing setfenv/getfenv in 5.2 (I don't remember any other use case coming up in the list which wasn't covered elegantly by other 5.2. features).o Is there a reason this idea [1] was scrapped?goto is more flexible and easier to write than break with labels (which usually demand a new block to add a label).o Also, since load is currently the only mechanism to set the _ENV upvalue without using the debug API, I'd like to see a generator for compiled chunks that let you set the _ENV upvalue: function _main (_ENV) return function (...) --[[ chunk ]] end endDoesn't that seem too specific? ("A mechanism to set the _ENV upvalue of binary chunks without using the debug API.") What is wrong with using the debug API for this very particular case?
-- Roberto
-- Lorenzo