Re: Incorrectness in the manual

["Soni L." <fakedme@...>]

On 2017-09-05 11:23 AM, Roberto Ierusalimschy wrote:
> > 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. Did you really understand that way?
> Has someone ever done?
>
> -- Roberto

I thought it meant the upvalues would be shared just like in Lua functions:

local v
function get(...)
  return v
end
function set(...)
  v = ...
end

(Would love if C functions supported full Lua function semantics, 
including shared upvalues. Sadly it seems not even the debug library can 
share C function upvalues:

debug.upvaluejoin (f1, n1, f2, n2)
Make the n1-th upvalue of the *Lua* closure f1 refer to the n2-th 
upvalue of the *Lua* closure f2.

Which I assume means C closures are unsupported.

Benefits of this would include no longer using the registry for 
io.input()/io.output(), thus making those functions faster by 
eliminating a table access.)

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.