Re: Globals (more ruminations)

[Mark Hamburg <mark@...>]

On Jul 15, 2010, at 9:04 AM, Roberto Ierusalimschy wrote:

>> "global checks" as a statement doesn't "turn on" global assignment
>> checking? Global assignment checking would be always on? Or is this
>> simply how it works at the file chunk level? (Perhaps a new thread
>> discussing the new change is warranted like the earlier "a new
>> proposal for environments" thread. It would be most helpful to have an
>> authoritative description of the proposed design.)
> 
> There is a good chance that this proposal will not go into 5.2; but
> anyway, just to make it clear:
> 
> - there is a new keyword "global" that can be used in the same places
> that "local" can be used (namely "global function ..." and
> "global a,b,c...").
> 
> - "global function foo ..." expands to "global foo; foo = function ..."
> (just like "local function" does).
> 
> - Names declared with "global" follow the same scoping rules of
> names declared with "local", in the same name space.
> 
> - Any use (access and assignment) of "a" in the scope of a "global a"
> declaration is translated to "_ENV.a".
> 
> - Any access to a free "a" (that is, outside any declaration for "a")
> is translated to "_ENV.a".
> 
> - Any assignment to a free "a" that is outside the scope of any
> other global declaration is translated to "_ENV.a".
> 
> - An assignment to a free "a" that is inside the scope of another global
> declaration is an error ("attempt to assign to undeclared variable
> 'a'").

I would suggest the following tweaks:

* "global a" as meaning that "a" should be interpreted as "_ENV.a" should be with respect to a specific definition of "_ENV". You may have already meant that, but I don't think you say so above. Which _ENV? My feeling is that it probably should tie to the chunk level _ENV, but I could be persuaded otherwise.

* To preserve existing module construction practice, introducing a new _ENV should eliminate the checks on global assignments.

Together this would allow:

	local _ENV = module( ... )

	function say_hello()
		global print
		print( "Hello" )
	end

The use of "global print" allows us to re-access the chunk level global despite the environment having been changed. That said, I could see arguments for wanting to use global within a module definition to handle forward definitions of functions.

One could also write:

	global print

	local _ENV = module( ... )

	function say_hello()
		print( "Hello" )
	end

This would not trigger an error for say_hello because it is being set into an environment other than the chunk level globals.

All that said, I'm not sure this buys enough to be worth the trouble.

Mark