lua-users home
lua-l archive

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


Matthew Wild <mwild1@gmail.com> writes:
> I have a sense that there's quite a divide growing between Lua and
> LuaJIT. I'm fine with this in general, there have always been various
> incompatible Lua spin-offs, that's what happens in the open-source
> world.
>
> 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 share the same worry.

> 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 totally agree with you.  I use LuaJIT, and it rocks, but I'm pretty
careful to not _depend_ on it.  I'd rather have my code work slowly in
some cases than not work at all.

However, I'd definitely like to take advantage of some features like
FFI.  Since I don't want to depend on LuaJIT, I wonder if a "halfway"
measure might prove workable for both LuaJIT, that allows specifying
interfaces in a way that can take advantage of much of FFI's speed for
LuaJIT, but still allow a less efficient mode of operation for standard
Lua.

My guess has been that this would entail using FFI's parser to
automatically produce C-code for a traditional Lua-C interface library,
but use dynamic FFI interfaces for LuaJIT.  Build-time configuration
could detect whether LuaJIT was available or not, and arrange for the
appropriate method to be used.

-miles

-- 
Freebooter, n. A conqueror in a small way of business, whose annexations lack
of the sanctifying merit of magnitude.