[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.2.0 (beta-rc1) now available
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Thu, 16 Jun 2011 06:03:53 +0200
On 13/06/2011 21.59, Roberto Ierusalimschy wrote:
o Is there a reason this idea  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 ]]
Doesn'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?
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).