Re: luaffi vs luajit ffi

[Cosmin Apreutesei <cosmin.apreutesei@...>]

On Tue, May 22, 2012 at 8:27 PM, James McKaskill <james@foobar.co.nz> wrote:
> On Tue, May 22, 2012 at 12:03 PM, Cosmin Apreutesei
> <cosmin.apreutesei@gmail.com> wrote:
>> I'm using luajit ffi for a month now. I found that it's not just a
>> library as it extends the language in some key semantics:
>>
>> (1) values of different types can be compared (Lua can't do that);
>> this makes things easier most of the time, and a tricky sometimes[1]
>
> There's really only two overloads that can't be handled:
> Ptr vs nil
> [u]int64_t vs number
>
> The problem is that lua will check the types before handing off to the
> metamethods. Lua 5.1 was worse in that it would never look up
> metamethods for mixed types. Lua 5.2 improves things by looking up for
> arith ops, but not for comparison ops IIRC.

Right, so now we have 3 platforms (5.1, 5.2 and lj2) with notable
differences between them: can't use setfenv in 5.2, can't use _ENV in
5.1 and lj2, can't use 64bit numbers in 5.1 and 5.2, can't compare
pointers to nil with luaffi etc.etc.

If one writes a binding nowadays it's easy to get locked in. I'm
currently locked in big to lj2 :)

>
>> (2) type(cdata) == "cdata" -- so now we have the 9th Lua type -- ok
>> you can overload type(), but maybe ffi.type() similar to io.type()
>> would have been better, dunno.
>
> type and tonumber are/will be overloaded. Thanks for mentioning type
> btw I have added it to my todo list.

Alternatively, you could add ffi.type() as one can easily alias type
with `ffi.type = type` for when the jit ffi is used.

> Other items:
> LL ULL, and i extensions to the parser to generate int64_t, uint64_t,
> and complex respectively.

I've used these too, but I guess I'll switch to ffi.cast('uint', -1)
etc. for more portability.

>
>> I don't think you can make luaffi a drop-in replacement for lj ffi
>> without patching Lua to address (1) am I right?
>
> You can get pretty darn close. The main one people hit is the
> comparison against nil for pointers. I added a ffi.C.NULL as a
> replacement.
> On my todo list is to move and/or copy this to ffi.NULL
> (or ffi.null) that way ffi.NULL would resolve to nil under luajit and
> the same code can work under both libraries.
>
>> [1] for a null pointer a, `a == nil` is true but `not a` is false and
>> `a = a or default` is not the same for a null pointer a and for a nil
>> value a.
>
> Frankly this goes to show that the ptr == nil breaks lua semantics, but alas.

More annoying is that applying == to a cdata raises an error which
never happens in Lua, so say you have a function in some library that
does a linear search for a value in a table with ==, if there's a
cdata in that table your function will break.

>
> At the moment the bigger issue w.r.t using the same code under both
> luaffi and luajit is the slight difference in semantics (e.g. casting,
> etc). These are mostly just bugs and polish.
>
> As always if you find any issues where a bit of code works under
> luajit but not under luaffi, please submit an issue to github
> (https://github.com/jmckaskill/luaffi/issues).

I'll give it a try after I have a stable enough code base with lj2.

>
> -- James
>