LuaJIT FFI vs Lua binding vs Lua interface

[Dirk Laurie <dirk.laurie@...>]

This post was inspired while pondering on the word 'currently' in
the following remark of Stefano:
>
> On a related note, I have decided to progressively release a number of
> libraries with scientific computing focus.
>
> As such libraries currently target LuaJIT 2.0, it was my intention to
> make the announcement on the LuaJIT mailing list if nobody is against
> it. Please let me know if there are objections to this :-)
>

The problem is not a rare one.  There is some rather substantial
C library with a well-documented API (examples: GSL, tcl-tk, but
there are literally hundreds of them).  It is desired to use this
library from inside a Lua program.  There are three main ways to
do this:

1. Lua binding

The names of the routines and their parameters stay the same.
You write a C program that grabs the arguments off the Lua stack,
makes sure that everything is of the correct type, calls the
appropriate C routine, and stuffs the return values back on
the Lua stack.  There are tools (SWIG etc) that relieve much
of the tedium.

2. LuaJIT FFI

This has much the same effect as Lua binding, except that you do
very little C programming. It usually requires no more than merely
supplying the headers of the routines to LuaJIT.  There is a Lua FFI
which does this sort of thing too , but I have the impression that
it is not nearly as widely used as the LuaJIT FFI.

3. Lua interface

The library is essentially added to Lua as a userdata.  The desired
features are integrated into a user interface catering for a Lua-like
way of thinking and you don't need to know anything about the
the parts of the library that have not been included.

Now methods 1 and 2 are of course by far the easiest.  In particular,
there is not much need to write documentation, since the original API
documentation can by and large still stand.

But method 3, ah!  When it is done well, as in the standard `file`
library or in Francesco Abbate's GSL-shell, what a pleasure!