lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Mark Hamburg <> writes:

> On Jan 8, 2010, at 9:10 AM, David Kastrup wrote:
>> Matthew Wild <> 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