Incorrectness in the manual

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Incorrectness in the manual

Egor Skriptunoff-2
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).

Please fix the manual.
Replace
"...all functions are created sharing nup upvalues, which must be previously pushed on the stack..."
with
"...all functions are created having its own independent upvalues initialized with the same nup values, which must be previously pushed on the stack..."

-- Egor

Reply | Threaded
Open this post in threaded view
|

Re: Incorrectness in the manual

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. Did you really understand that way?
Has someone ever done?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Incorrectness in the manual

Soni "They/Them" L.


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.


Reply | Threaded
Open this post in threaded view
|

Re: Incorrectness in the manual

Philipp Janda
In reply to this post by Roberto Ierusalimschy
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



Reply | Threaded
Open this post in threaded view
|

Re: Incorrectness in the manual

Roberto Ierusalimschy
> [bla-bla-bla] Anyway, there would be no need to push an upvalue to the
> stack.

The manual says: "all functions are created sharing nup upvalues,
which must be previously pushed on the stack". So, if you are going to
interpret the manual literally, you do need to push an upvalue to the
stack.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Incorrectness in the manual

Doug Currie
On Mon, Sep 11, 2017 at 9:34 AM, Roberto Ierusalimschy <[hidden email]> wrote:
> [bla-bla-bla] Anyway, there would be no need to push an upvalue to the
> stack.

The manual says: "all functions are created sharing nup upvalues,
which must be previously pushed on the stack". So, if you are going to
interpret the manual literally, you do need to push an upvalue to the
stack.


Perhaps it is confusing because all other mention of "share" w.r.t. upvalues is in contrast to "fresh" upvalues.

e