Re: [ANN] LuaNativeObjects a C bindings generator with FFI support

["Robert G. Jakabosky" <bobby@...>]

Sorry for the late reply.  I was in the middle of writing this e-mail, when I 
got interrupted and it got lost behind my other windows.

See comments below.

On Saturday 26, David Manura wrote:
> On Fri, Feb 25, 2011 at 10:42 PM, Robert G. Jakabosky
> 
> <bobby@sharedrealm.com> wrote:
> > It might be possible to do something like:
> >  c_call "int" "function_name" { P"int x", P"int y" }
> 
> I'm a little wary of using tricks with Lua syntax to accomplish DSL's
> in the manner seen in LPeg (without re) [1] and Coat [2].
> Syntactically it sort-of resembles in a declarative way what we're
> trying to represent, but uglier.  Semantically, it's a whole different
> bag of crazy tricks underneath, and the user might not be isolated
> from this.  At least with LPeg, the stated justification [1] is for
> patterns to be manipulatable as first class objects in Lua, and the
> semantics are not that far off.
> 
> Alternate options include keeping the syntax pure data (e.g.
> XML/s-expressions/JSON or plain Lua tables, like in LuaRocks
> rockspecs), implementing a nice parser (like Mike did for FFI and
> Roberto did for LPeg re), or using a more imperative OO builder-like
> approach (as in Scons and others [3-4]).  The imperative style may be
> worth considering:
> 
>   local m = module "gd"
>   m.constructor {name='newTrueColor', callstyle='ccall', ret='gdImage
> *', symbol='gdImageCreate', parameters={ "int", "sx", "int", "sy" }}
>   m.constructor[[newTrueColor ccall gdImage * gdImageCreate(int sx,
> int sy)]] -- possibly with shorthand too
>   if condition then -- the imperative style permits control structures
>     m.destructor {.....}
>   end

I don't see how that first "m.constructor.." line is any easier to read/write.  
Also for the second one, how would you handle a block of custom C code for 
binding a complex C function that doesn't have a simple parameter types? or 
output parameter? or object ownership transfer?

When starting the LuaNativeObjects project I had looked at using sparse [1], a 
LPEG C Lexer [2], or even a LPEG C99 parser [3] to use a bindings syntax 
something closer to C's syntax.  But I decided against that when I found that 
I could easily create an AST-tree using a few simple Lua functions the make 
Lua into a simple bindings DSL.  I still don't like all the extra quote " 
marks that are needed around the names and types, but I can live with them for 
now.

The nice thing about using Lua as a DSL is that it is very flexible and easy 
to add features.

> [1] http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html
> [2] http://lua-users.org/lists/lua-l/2009-08/msg00378.html
> [3] http://www.scons.org/doc/production/HTML/scons-man.html
> [4] http://lua-users.org/wiki/LuaBuildSystems -- e.g.
> env.Program{'hello', 'hello.c', LIBS={'gl', 'glut'}}

1. https://sparse.wiki.kernel.org/index.php/Main_Page
2. http://lua-users.org/wiki/LpegRecipes
3. http://article.gmane.org/gmane.comp.lang.lua.general/58453

-- 
Robert G. Jakabosky