Re: [ANN] lglob 0.8 Extended Globals Checker for Lua

[Tim Hill <drtimhill@...>]

Ok so my 2c worth having read the discussion of the past few days.

First, is there really a problem? At the language level, I think not. I really like the overall Lua model, the elegance of globals as just another table, _ENV, and all that goes with that. But at the secondary "human" level than yes, I think there is a problem. Only a few weeks ago I was bitten by a very subtle spelling bug in a global that I stared at for TWO DAYS until I spotted it. Even though I more or less KNEW what it had to be. Argh, more gray hairs :)

Second, what to do? I don't like some of the suggestions: Changing the language makes me shudder; if every change suggested in this list were enacted Lua would be a bigger mess than JavaScript. I also get scared by tools that try to duplicate some aspects of the parser -- it's asking for trouble.

But the best parser is, well, Lua itself!! Deep inside Lua is a block of code that knows when it has a global variable and converts "x" to "_ENV.x" .. that's fundamental to the way the language works now. It seems to me that the best approach would be to modify luac and add a switch to get it to emit a line of output each time it prefixes "_ENV" onto a global/free variable. Something like the line number, column number, and variable name. With this as input, it should be easy to create analysis tools that then provided information on globals usage (that mis-spelled global would easily be found).

Of course, such a tool is mostly useful for "batch" mode on complete Lua programs, rather than the partial ones that editors have to deal with.

--Tim



On Apr 29, 2013, at 4:12 PM, Petite Abeille <petite.abeille@gmail.com> wrote:

> 
> 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.
> 
> 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?
> 
> I suspect not… oh, well… so much for global checker I guess...
> 
> 
> 
> 
>