 |
lua-l archive |
|
|
||
|
Am 30.04.2013 01:12 schröbte Petite Abeille:
On Apr 30, 2013, at 12:27 AM, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:But... now I'm a bit confused by what you consider a, err, 'global'?Yes, I think Lua 5.2 now blurs the distinction between free variables and fields in _ENV. Once it applies the transformation x -> _ENV.x, there is no way by looking at the generated code to know that x was once free. Thus, being practical, "global" must mean a field of _ENV, not a free name.Hmmm… yes… perhaps practical in the sense of feasible, but not practical in the sense of useful.
Depends on how (often) you use _ENV.
When referring to 'global' one colloquially understands 'global in the global environment' … global global so to say… not, err, local global in a, hmmm, local environment… which is as interesting as having keys in any old table… in other words, not very much. Is there a way, in 5.2, to identify these 'global global' through byte code analyses? In the same way one could clearly and easily identify global access by checking for ([GS])ETGLOBAL in 5.1?
It wasn't possible in Lua 5.1 either in the presence of setfenv (and module).
I suspect not… oh, well… so much for global checker I guess...
I propose the following definition of "globals" in the context of static global checkers:
* Any access to a chunk's _ENV upvalue (not a local variable) is a globals access, unless the chunk itself or any function sharing the same _ENV upvalue potentially assigns to the _ENV upvalue. * Any access to a functions _ENV upvalue (not a local variable) is a globals access, if the _ENV upvalue of the chunk was the only _ENV in scope during the functions definition *and* unless any function sharing the same _ENV upvalue potentially assigns to the _ENV upvalue.
* Anything else not covered above is not a globals access.I believe that is both useful and still statically checkable (with some effort). We won't get `module` without `package.seeall` right (or any other use of `debug.setupvalue` to change _ENV), but that's deprecated anyway.
That said, since I don't use _ENV tricks that often, I'm quite satisfied with the state of the global checkers ...
Philipp