Re: Oh no, it's the "global" issue again

[niklas <niklas@...>]

> I do agree that the semantics of it got very complicated. My feeling is
> that too much functionality was associated with the keyword. Function
> environments (setfenv) replaced the keyword and are more powerful, but
> don't cover all of the functionality that "global" was supposed to
> supply (e.g. limited static testing).
> 
> Nick
> 

I have extracted a portion of luac into a routine for listing all globals in a
script by examing GETGLOBAL instructions.  I would like to see such
functionality folded into the core libraries as it is useful in a number of
contexts:

1) Very easy to write a "lua-lint" that flags all global variables

2) Allows me to glue together collections of expressions input by a user (a la
Excel) and look up all unbound global variables in a database. Makes simple
spreadsheets easy.  In addition, if you know the unbound globals you can wrap
all the subexpresions in a function definition and turn the "globals" into
parameters.  Much faster execution if the expressions must be evaluated for many
candidate data sets.

3) Easy to auto generate documentation.

I suppose that this could be implemented by having hooks in the code generator
that call a user provided function along the lines of:

void GetGlobalHook(const char* name, void* userProvidedParameter)
{
   if (NotSeen(name))
     printf("New global variable %s\n", name);
} 

For my purposes, I would also like a SetGlobalHook that lets me tell if the
global was defined in Lua or whether I need to fetch it from another environment.

The problem with using setfenv is that you can only intercept the newindex calls
at run time. This means that you must exercise all code branches somehow to
catch all global accesses.  Very difficult to do automatically.



Niklas