Re: Backport of Lua 5.2 "in" scoping

[Mark Hamburg <mark@...>]

On Jan 9, 2010, at 2:01 AM, David Kastrup wrote:

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

You're right it doesn't contradict what you said about what happens. I had keyed in on your phrasing about "already resolved symbols". There's nothing already resolved about print in sayhello. If you do setfenv (or debug.setfenv) on sayhello it can change what print gets directed to.

The inheritance of scopes bit I think came from something else on this thread and I got my answers mixed.

Mark