lua-users home
lua-l archive

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

On 22/02/2011 3.57, Matthew Wild wrote:
However LuaJIT is so popular, and its popularity only set to increase,
I'm worried that this could be the start of fragmentation such as we
have never had to deal with before in Lua.

I don't begrudge LuaJIT its fancy features (in fact I love them, and
have plans to use the FFI for some projects). I think this is more a
community responsibility - if we don't want to be in the position 12
months down the road where half the modules available for "Lua"
actually work only on LuaJIT and the platforms it supports.

I was thinking along the same lines. I would feel a lot more comfortable using LuaJIT FFI (which is great!) if I knew I could maintain as much plain Lua compatibility as possible. Ideally, one would like to be able to write FFI code once and produce not two but three different outputs from the same 'source':

- off-the-shelf Lua + alien: slowest, but no C required.
- off-the-shelf Lua + automatically generated C/C++ bindings: better performance but some hassle due to external C compilation, different compilers and compiler options, linking, platform problems, etc.
- LuaJIT with FFI: best performance, no esternal compilation required.

This 3-pronged output being probably too complex and costly to maintain, if I had to choose I'd prefer to keep the first and the last one, i.e. pure Lua + alien if I don't want to spend time to make bindings work, and LuaJIT when I need performance (assuming the platforms I'm developing for are supported by Lua JIT).

In this case, 'only' a LuaJIT-FFI --> alien converter (possibly including an embedded C intepreter) would be needed. An interesting problem :-)