Re: Backport of Lua 5.2 "in" scoping

[David Kastrup <dak@...>]

Mark Hamburg <mark@grubmah.com> writes:

> 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.

You phrase this as though it should contradict what I say.  But I don't
see where it would.

-- 
David Kastrup