lua-users home
lua-l archive

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

As a small side note, someone is actually attempting to rewrite Lua and Lua's C API to be more performance-friendly with C++[1]. They might come up with other good ideas relevant to making the API more idiomatic, maybe!


On Sun, Feb 25, 2018 at 8:19 AM, Soni "They/Them" L. <> wrote:

On 2018-02-25 01:28 AM, Coda Highland wrote:
On Sat, Feb 24, 2018 at 9:33 PM, Soni "They/Them" L. <> wrote:
Lua's C API is not idiomatic. I don't see setjmp/longjmp used by things like
POSIX (as far as I know nothing in POSIX says you have to use setjmp/longjmp
to handle errors) or libuv.

It would be more idiomatic to return error codes, and have the caller
propagate errors. (Using setjmp/longjmp internally is fine tho.)

This would also increase compatibility with some libraries and programming
It is, as is the case with so many things, a tradeoff.

setjmp/longjmp is faster at runtime and simpler to code. It does of
course have a lot of limitations you have to be careful with, but
error codes also have a lot of things you have to be careful with --
among other things, using error codes implies using out parameters,
which is pretty smelly in its own right.

Certainly the compatibility note is, well, noteworthy. But it doesn't
seem to be worth the cost of refactoring the entire Lua codebase and
API (thereby breaking literally every single C extension ever written)
to accomplish that when you can write API wrappers to adapt Lua to
work in the other environments (possibly using C++ mode).

Don't forget that Lua is stackless, so any errors only have to go as far as about a handful of stack frames anyway.

(Unless you're using something like lua_call. Not something I see often, tho. Plus, you'd get to handle cleanup (freeing OS resources) *while keeping the original backtrace*!)

/s/ Adam

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.