Re: LuaJIT without the JIT?

[Peter Odding <peter@...>]

> Hm, this thread seems to have gone way off course, and even before
> that it was more discussion about LuaJIT in particular.

For the record I think you expressed yourself pretty clearly in your
initial message. Threads on lua-l just tend to derail into (interesting
but nonetheless) off-topic discussions pretty quickly :-).

> I asked about LuaJIT simply because it compiles Lua code into native
> code. I understand now that trying to make it compile into *static*
> native code is infeasible. Is there any work being done on a static
> compiler?

Static compilers for Lua exist in several forms, e.g. LLVM-Lua [1] and
lua2c [2], but they are not specifically focused on creating binary
modules loadable from regular Lua (AFAIK), let alone binary modules that
bind external libraries.

> I'm finding it a little difficult to explain exactly what I'm thinking
> of (as I often do :). Right now if you want to write a binding to a C
> library, there are two ways you can do it:
> 1) Write it in C and compile it into a module as a shared library.
> 2) Write it in Lua using LuaJIT's FFI or other FFI module.
> Option 1 creates a module with no external dependencies, but requires
> you to write the library in C. Option 2 lets you write it in Lua, but
> the resulting module is dependent on the FFI module you use. What I'm
> interested in is the possibility of writing binding modules in Lua,
> then compiling them into shared object files as native code, thus
> eliminating the runtime dependency on any FFI library.

Bindings written using the LuaJIT FFI are free to use as little or as
much of Lua (both the language and standard library) as is useful to
create the binding. This means that AFAICT the static compiler would
have to support most of Lua (the language and standard library) and
compile it down to C. Even with runtime support from liblua I don't see
this happening anytime soon.

A plausible alternative take on this would be to implement something
like Pyrex [3] for Lua. Pyrex is a programming language that looks a lot
like Python but is closer to C and much simpler. It can be used to
implement Python C bindings without having to write any C, just Pyrex
flavored Python. A similar language for expressing Lua (FFI) binary
modules could be much easier to compile down to C.

I've given some serious thought to this last option because I wrote the
Lua/APR binding and I love that it's gotten pretty reliable now (because
of all the tests) but it certainly took me long enough to get there!
Even just C with better macros would have helped a lot -- I find myself
generating C code in Lua now and then because C is not a very flexible
language at all :-)

 - Peter

[1] http://code.google.com/p/llvm-lua/
[2] http://lua-users.org/wiki/LuaToCee
[3] http://en.wikipedia.org/wiki/Pyrex_(programming_language)