Re: LuaJIT without the JIT?

[HyperHacker <hyperhacker@...>]

On Fri, Jun 24, 2011 at 00:47, steve donovan <steve.j.donovan@gmail.com> wrote:
> On Thu, Jun 23, 2011 at 11:07 PM, Francesco Abbate
> <francesco.bbt@gmail.com> wrote:
>> system or something similar. The fact that you have no types at all
>> and no warnings of any kind even for a small typing error is terrible
>> when you develop something even moderately complex. In addition you
>> don't even have a debugger so it is even more painful.
>
> So that would seem to be a big priority: push the tooling to a new
> level.  Once my runway is cleared of scheduled flights, I can get back
> to my old interest in Lua debugging, based on the clidebugger module.
> It works well enough in SciTE, and I am going to do a careful revisit
> of LuaGDB for Emacs.  The situation can certainly be improved, but it
> isn't easy work (debugging debuggers tends to push the brain a lot)
> (There is also Decoda, which is a commercial product)
>
> As for type information, one way is 'explicit type annotations'.
> Metalua allows that as an extension, and LuaMacro can do that as well;
> one can choose to generate code that throws assertions on declared
> types as well.  But I mostly see type annotations as a 'code as
> documentation' extension.
>
> (The interesting flip-side of syntax extensions is that you need a
> corresponding extensible documentation tool as well, which is one of
> the future directions for ldoc.)
>
> steve d.
>
>

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

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?

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.

-- 
Sent from my toaster.