lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> <> 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 

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

> [1]
> [2]
> [3]
> [4] -- e.g.
> env.Program{'hello', 'hello.c', LIBS={'gl', 'glut'}}


Robert G. Jakabosky