[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] LuaJIT Roadmap 2011
- From: Miles Bader <miles@...>
- Date: Thu, 27 Jan 2011 11:02:40 +0900
Mike Pall <firstname.lastname@example.org> 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.
Neighbor, n. One whom we are commanded to love as ourselves, and who does all
he knows how to make us disobedient.