Re: Globals (more ruminations)

[Mark Hamburg <mark@...>]

On Jul 15, 2010, at 10:31 PM, Ricardo Ramos Massaro wrote:

> On Fri, Jul 16, 2010 at 1:51 AM, Mark Hamburg <mark@grubmah.com> wrote:
>> * "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.
> 
> But what if a module writer *wants* the new check for his modules? In
> Roberto's proposal, we can go from this:
> 
> # -------
> local _ENV = module(...)
> global function set_x(new_x)
>   xx = new_x  -- silent error: I meant "x" instead of "xx"
> end
> # -------
> 
> to this:
> 
> # -------
> local _ENV = module(...)
> global x   -- declare x and enable checking
> global function set_x(new_x)
>   xx = new_x  -- compiler error: attempt to assign to undeclared "xx"
> end
> # -------

That would work with regard to my second point, but would mean that my first point couldn't treat global x as an escape hatch back out to the chunk-level globals. I don't have a strong opinion on that. My key point with regard to eliminating the checks was that if you switch _ENV then the previous global declarations no longer apply to the current global environment and hence checking there would seem inappropriate as well.

That said, switching _ENV in many cases seems a bit of a hack to try to exploit the support for "lightweight globals" as a way to avoid a bit of typing.

Mark