David, You seem to be reading more into the suggestion than was intended - all I suggested was a change in *default* behaviour which by definition only alters syntax. Locals still work exactly as before, just you do not need the "local" keyword (unless you want to restrict the scope of a local further). Globals still work as before, just if you want to assign to one you need to use table syntax (or there could be a global keyword as sugar for this). You can still *access* a global without table syntax, so "print" is still global because its library would have explicitly inserted it in the global table. In your example, "n" would now be a local at the outer lexical scope, so all the inner references would see it and would therefore *not* create new, more local, variables. If you *wanted* to create a more local "n" you'd still have to use the local keyword. "global" still refers to the global environment table - you can be "more local" but you cannot be "more global", you can only be "global". As for the "foo" variable referencing the function, I agree that would need some thought. In the pure form, that would become an outer scope local as well and you'd have to use "_G.foo" if you wanted it to be global. However the existing syntax sugar gives a convenient and natural exception mechanism for functions if we want. The sugar form of function creation, as your example, could still be global-by-default while the native form would be local-by-default in line with all other variable assignments. The suggestion does not alter the language in any fundamental way, just the "path of least resistance" for naive (or in my case, careless!) programmers. - John -----Original Message----- From: David Given [mailto:dg@cowlark.com] Sent: 20 February 2008 15:56 To: Lua list Subject: Re: Implicit Globals - A compile time solution. Examine the following code: n = 1 function foo() return function() return function() if bingy then print(n) end print(n + 1) end end end
Attachment:
smime.p7s
Description: S/MIME cryptographic signature