Re: Incorrectness in the manual

[Philipp Janda <siffiejoe@...>]

Am 05.09.2017 um 16:23 schröbte Roberto Ierusalimschy:
> > Hi!
> >
> > Lua manual contains very misleading incorrectness.
> > According to manual, "luaL_setfuncs" SHARES upvalues among all the
> > registering functions:
> > (quote)
> > When nup is not zero, all functions are created sharing nup upvalues, which
> > must be previously pushed on the stack on top of the library table.
> > (end of quote)
> > But that's not true.
> > Actually, each function gets its own separate upvalues.
> > These upvalues are initialized with the same values, but upvalues are NOT
> > SHARED between functions.
> >
> > This is very confusing.
> > For example, one could think after reading the manual that using
> > "luaL_setfuncs" it is possible to register set of two functions: "set" and
> > "get" sharing the same upvalue, which is being set and get.
> > But this direct solution will not work.  Instead, some workaround is
> > required (such as using a container holding the shared value).
>
> Actually, for your interpretation, one would need to find a way to
> push an upvalue in the stack.

With a new internal type tag (e.g. LUA_TUPVAL) the lightuserdata 
pointers in the TValues in the CClosure upvalues could be (ab-)used to 
point to UpVal structures similar to how Lua closures do it. The normal 
TValue upvalues in a C closure could be changed on demand when the 
upvalue is target of a `lua_upvaluejoin` call. `luaL_setfuncs` could do 
that for all its functions and upvalues, or we could add a new `luaL_` 
API function that really creates C closures with shared upvalues, or we 
let developers handle it manually when it's really needed. Anyway, there 
would be no need to push an upvalue to the stack.

> Did you really understand that way?
> Has someone ever done?

There was a stackoverflow question regarding shared upvalues of C 
closures a few days ago, and I found an old mailing list thread from 2006.

> -- Roberto

Philipp