[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: implementation of lexical scoping
- From: Roberto Ierusalimschy <rieru@...>
- Date: Wed, 3 Oct 2001 15:59:35 -0500 (CDT)
On Tue, 2 Oct 2001 RLake@oxfam.org.uk wrote:
> I remain with one question, and one suggestion. The question is probably
> easier: will C closures be presented with the same interface? That is, will
> C closures (need to) use some API call to indirect through to the value of
> an enclosed binding, and therefore have the ability to rebind, or will they
> be presented with "unbound" (resolved) values rather than bindings?
We intend to keep C closures immutable, but maybe we will change the API to
something similar to that proposed by ET. Instead of the upvalues comming
on the top of the stack, they will be accessible through special indices
(generated by a macro "lua_upvalueindex(i)").
> For example, such an implementation might provide an API like
> lua_getbinding(L, i) / lua_setbinding(L, i) which push / pop the stack from
> / to the indexed binding. Moderate compatibility with old code could be
> provided with the API lua_pushbindings(L) which pushes (the values of) all
> enclosed bindings onto the stack, effectively emulating the current
> implementation.
The idea of a lua_pushbindings function seems interesting. We also should
provide a compiler option to keep the old behavior. (That is, to
automatically call "lua_pushbindings" before calling a C function.)
But I don't feel a need for a lua_setbinding. It is all to easy to put a
table as the upvalue, and then put mutable values inside it. Using numerical
indices and the new API, we should be able to get/set those values with a
single API call: «lua_rawgeti(L, lua_upvalueindex(1), MY_KEY);» In this
way, it is also easy for several functions to share a same table as their
upvalue, so that updates are "global" within those functions.
-- Roberto