 |
lua-l archive |
|
|
||
|
I can definitely see the performance benefit if you're only interested in passing the first return value of a function to another function and don't want to create a local variable -- saves a bunch of unpack({ function(...)}, 1,1) calls which'll construct a temp table, and saves a variable lookup when capturing that first arg with "local x = function(...)" just to pass it as a function arg in the next code-line.
Though, I'll admit, I don't see how it saves "{ if (lua_gettop(L) > 3) luaL_error(L, "too many arguments!") }" code within the lua libs. Other than the inefficiencies of pushing more args onto the stack than a function needs, does it really matter if you pass 15 arguments to a function that only wants/needs 3? It can just silently ignore those last 12 args.
<quote>..but more importantly you can use function calls inside a parameter list to another function and not worry that'll it return a bunch of values clobering yours.</quote>
Presumably if you're calling a function that returns multiple arguments, you know how many return values it has and can adjust accordingly; even if you don't have an exact number, you can wrap it in "unpack({function(...)}, 1, n)" in the worst case. If that's too inefficient, due to table construction, then add a new function to Lua -- firstn(n, ...) returns up to the n arguments 2 through n+1 -- then just use "firstn(1, function(...))"
<shrug>I guess I just don't see how having inconsistent behaviour is desirable; the behaviour being defined this way doesn't make it any less inconsistent. function(...) pushes all of its return values onto the stack; but, if you call another function before popping the stack then you lose all but the first return value. Seems so very strange.
I'm sure there was a long discussion that resulted in this behaviour, so I'll accept it and kludge around it; just wanted to voice my opinion. ;-)
-Daniel Alex Davies wrote:
It may seem strange at first, but the benefits are large. There's the performance aspect, but more importantly you can use function calls inside a parameter list to another function and not worry that'll it return a bunch of values clobering yours. The last argument is allowed to overflow - there's a reason you don't see a bunch of { if (lua_gettop(L) > 3) luaL_error(L, "too many arguments!") } in the lua libraries. :)- Alex From: "ddneilson" <ddneilson@gmail.com>Hm, so it is. It's such an odd behaviour (read: counter intuitive to me) that I honestly didn't think for a second that it was actually intentional! <shrug>