Re: Why are people so afraid of globals?

[David Manura <dm.lua@...>]

On Fri, Jul 9, 2010 at 12:32 PM, Mark Hamburg <mark@grubmah.com> wrote:
> Say there were a new statement of the form:
>         global var1, var2, var3

The above proposal and the previous proposal for

   import var1, var2, var3 from foo
   --> local var1, var2, var3 = foo.var1, foo.var2, foo.var3

I would suggest be unified as such:

  global var1, var2, var3 in foo
  local var1, var2, var3 in foo

Both statements would achieve a similar effect and in many cases would
be interchangeable.  They would both introduce lexically scoped names
associated with corresponding variables in a table.  The difference is
the implementation.  The latter would cache the values as locals (on
the stack registers).  The former doesn't allocate anything in the VM
but rather merely provides a convenience syntax allowing, for example,
`foo.var1` to be written as just `foo` in the lexical scope, so it
still triggers a table index and any __index and __newindex
metamethods.  (I would normally prefer writes to variables declared
with `global` to be disallowed though since I rarely have a need to
write to global variables and if its really needed the longer form
`foo.var1` remains an option.)  The former doesn't waste any register
space, although in the latter the compiler could optimize away
allocation of locals that aren't referenced in the lexical scope.

The main complaint is that I see this perhaps leading to long
preambles like this in every program file (which at least is better
than the "local assert = _G.assert" technique some use in 5.1):

  global _G, _VERSION, assert, collectgarbage, dofile, error, getfenv,
getmetatable, ipairs, load, loadfile, loadstring, module, next, pairs,
pcall, print, rawequal, rawget, rawset, require, select, setfenv,
setmetatable, tonumber, tostring, type, unpack, xpcall in require"_G"

That's why I suggested in my previous post that luac itself build this
list automatically, such as (for example) loading the "_G" module and
testing every unrecognized identifier within the lexical scope for
non-nil values in that table.  But that suggestion may be
controversial.