Re: [ANN] LuaJIT Roadmap 2011

[Miles Bader <miles@...>]

Mike Pall <mikelu-1101@mike.de> writes:
>> I understand that the FFI is tightly integrated, and for good reason,
>> but how coupled is the C parser to the rest of luajit? That's a tool
>> that could have many uses as part of other programs as well.
>
> The C parser and the C type management rely on interned strings,
> but otherwise have relatively few dependencies on the VM. But it's
> designed as a declaration parser only. It captures what I needed
> for the FFI, but ignores everything else.
>
> I'm sure there are better and more flexible C parsers out there,
> if you need to inspect C code. Maybe not with such a low memory
> footprint, though.

FFI seems very cool but the reliance on LuaJIT is an issue.  For normal
Lua programs, the fact that one can fall back to the portable Lua
implementation is a very nice property.

So I'm wondering:  if your C parser is (theoretically) usable outside of
LuaJIT, maybe it could be used as part of a tool that automatically
generates traditional Lua-C interface functions, which could then be
used when LuaJIT isn't available -- on systems where LuaJIT _was_
available, of course, one would use fast FFI (choosing between the two
alternatives at package build time).

For such a scenario, the fact that it was the same parser that
LuaJIT-FFI uses would be a real benefit.

-miles

-- 
Neighbor, n. One whom we are commanded to love as ourselves, and who does all
he knows how to make us disobedient.