[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT FFI vs Lua binding vs Lua interface
- From: Francesco Abbate <francesco.bbt@...>
- Date: Thu, 21 Jun 2012 18:47:20 +0200
2012/6/21 Dirk Laurie <email@example.com>:
> 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.
I would like to make some considerations on this topic. I've a
substantial experience both writing classic Lua C API and LuaJIT2 FFI
interface and what I've seen is that with FFI it is *much* more easier
to interface with a C library. The developing time is divided by 10
may be, the code is much simpler and readable, and you can still use
all the metamethods including the __gc hook to finalize objects.
In my point of view the FFI interface is so much interesting that it
would be a benefit for Lua, as a programming language, to adopt it as
a standard library.
A pure Lua FFI implementation already exists but AFAIK there are
actually some corner case differences with the real LuaJIT FFI. If FFI
was adopted and standardized into the Language we could come out with
two equivalent implementations and this would be a great benefits for
many Lua programmers. You could have all the benefits of the FFI
interface and still choose freely between Lua and LuaJIT2.
> 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!
Thank you, Dirk! I'm glad that someone appreciate my work on gsl shell :-)
I strongly believe that one by one bindings to a C library add little
added value for the users. For a Lua binding to be valuable you need
to offer a properly thought Lua interface to really take advantage of
Lua's simplicity. This is what I tried to do with gsl shell with both
the graphical library and the GSL itself itself.