Re: Backport of Lua 5.2 "in" scoping

[Mark Hamburg <mark@...>]

On Jan 8, 2010, at 9:10 AM, David Kastrup wrote:

> Matthew Wild <mwild1@gmail.com> writes:
> 
>> I'm interested whether the patch is correct. From the other thread I
>> thought I understood that functions would stop using the environment
>> they were defined in by default, and instead the environment they are
>> called in. Such that this simple example would fail (due to lack of
>> print in env):
>> 
>>   function sayhello() print("Hello") end
>>   env = { sayhello = sayhello }
>>   in env do sayhello() end
>> 
>> Am I wrong in my understanding?
> 
> I think so.  Since no local "print" exists at the time of compilation,
> this is resolved at compile time to the equivalent of
> 
> _G.print("Hello")
> 
> Now if you change _G.print, this will affect sayhello's operation I
> should think.  But "in" does not touch _G AFAICT, merely sets it aside
> for the purpose of resolving symbols.  Already resolved symbols will
> retain their resolution (though not necessarily their value).
> 
> That's my understanding.

This works not because of any inheritance on scopes but because sayhello is defined outside the in construct and hence gets the main global scope as its environment rather than env.

Mark