lua-users home
lua-l archive

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




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.