lua-users home
lua-l archive

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

> This looks quite explicit and I doubt that tail call optimization
> 'spans' C function calls (you'll have to call func from C code,
> right?) .

I meant that "take" is akin to tail call optimization listed below, not that tail call optimization takes places there. All the function needs is a call to lua_callk (k to allow yielding from inside).

> Having this in the debug library somehow decreases its usefulness. Why
> would you want to obtain the number of results from any level other
> than the reasonable one?

Because it is not trivial to use the returned value from Lua, and changing the observable behaviour of a function based only on this value is bad. Frankly, the same issue is there when using the C API as well, but working with the stack makes using the number correctly much simpler (and I suppose C programmers would be more careful in general when working with the API). Providing the level fits well with the rest of the debug package and could be necessary to make helper functions for use in other functions.

> if the computations involved are really expensive, I'd rather pass an explicit argument
> around saying which ones I want so that some minor refactoring doesn't
> trip me further down the road. The usefulness of all of this breaks
> down when you e.g. have a function returning a,b,c and want a and c
> but not b. Passing around an explicit table like {a=true,c=true} is
> simple and generic, and code says what you mean; table creation can be
> lifted to avoid excessive garbage.

I agree that for example how debug.getinfo is designed is much better for complex functions and numerous returned values, but in cases where the returned values are somewhat inclusively ordered (i.e. obtaining b makes sense only if you obtained a as well; c only if b etc.), and (probably the largest use) for distinguishing between zero or more return values, it makes it simple yet efficient. After all, this is not a proposal for a new convention, but a tool that can be used by libraries for slight explicit optimization.

> When I came to the third quote, I was baffled. Where do you plan to
> store the required value if not on the stack?

The value is stored in the Lua state for every function call, obtainable via L->ci->nresults from C (if lua_State is complete). The value is not stored on the stack, since it can be determined implicitly from every Lua call _expression_:

local a, b = f() -- 2
f() -- 0
local t = {f()} -- LUA_MULTRET (-1)