Re: [ANN] Lua 5.3.0 (work3) now available

[Patrick Donnelly <batrick@...>]

On Thu, Jun 19, 2014 at 4:32 PM, Luiz Henrique de Figueiredo
<lhf@tecgraf.puc-rio.br> wrote:
> All feedback welcome. Thanks.

For Reference Manual section 4.7:


(1)

Because of the example code, one might expect to be able to write
something like:

     int original_function (lua_State *L) {
       ...     /* code 1 */
       return k(L, lua_callk(L, n, m, h, ctx2, k), ctx1);
     }

but that doesn't work because the lua_callk return type is void. Maybe
lua_call[k] should return an integer, always LUA_OK? (For symmetry
reasons...) We could also have lua_yieldk return an int (LUA_YIELD),
but of course lua_yieldk always results in a yield and longjmp; it
would just look pretty.]


(2)

"For lua_yieldk and lua_callk, the status is always LUA_YIELD when Lua
calls the continuation. (For these two functions, Lua will not call
the continuation in case of errors, because they do not handle
errors.)"

seems to suggest that lua_yieldk may have an intervening error (as if
a call to lua_yield could cause an error instead of a yield). I had to
double check the manual that lua_yieldk cannot throw an error**. I
would advise framing this in reverse:

"status is always LUA_YIELD except for pcallk where status could be an
error code or successful completion (LUA_OK)."

However, it's no longer correct if (1) is adopted.


** Well actually it apparently can, if yielding across a C call
boundary or in the main thread. Is that an error in the manual?

-- 
Patrick Donnelly