Re: Backport of Lua 5.2 "in" scoping (was Re: Lua registry, environment, and threads.)

[Roberto Ierusalimschy <roberto@...>]

> Matthew Wild wrote:
> > 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? If so then the change really has less
> > consequences than I first thought.
> 
> The term "lexical scoping" implies a static effect on the definition and
> not a dynamic effect on calls.
> 
> Even when you move the definition inside the scope, there is no
> change due to this patch. The description lacks details on how
> environment inheritance is implemented.
> 
> Using the scope as the closure environment would need a change to
> the bytecode since OP_CLOSURE always copies the environment from
> it's calling function (and has no free argument left).
> 
> When/if the Rio oracle speaks again, I'll provide an exegesis in
> the form of a modified patch ... :-)

The "oracle" already spoke:

  A function *defined* inside a "in env do ... end" will be created with
  environment 'env'.

OP_CLOSURE changed. It does not need any extra argument; the stack index
of the environment to be used is stored in the struct ot the Proto being
instantiated. (The indices of the upvalues for the new closure also
are now stored in struct Proto, so that OP_CLOSURE does not need those
OP_MOVE/OP_GETUPVAL pseudo-instructions after it.)

-- Roberto