I've tried this out some tonight. This project seems to have a lot of
similarities with my own LuaFish project: http://lua-users.org/wiki/LuaFish ,
which is also a Lua 5.1 parser in LPeg under the MIT license. LuaFish includes
some optional (and experimental) modules with particular emphasis in
compile-time macros and static code analysis/validation applications, though,
like Leg, it can be applied to many applications.
I think there is room for collaboration and possibly even merging LuaFish and
Leg if it's determined they are sufficiently similar. I haven't myself gotten
around to updating LuaFish in the last few months, but if others have interest
in working further in this direction, that is great. Comparison of the PEGs
would at least be useful.
There's also room for collaboration between these projects and the more
established Metalua. For example, I've been discussing with Fabien at Metalua
about making the LuaFish AST structure identical to, or at least more similar
to, Metalua's AST structure (though I've had differences in opinion, at least it
can be said the Metalua AST is largely well thought out) and maybe even e.g.
eventually making some of my directions a subproject of Metalua. I don't think
Leg is using an AST, but it does have certain naming conventions for the rules
(e.g. NumericFor).
Leg isn't using an AST, but building one is easily done by piping (this terminology appears in doc/grammar.html) the appropriate captures to the grammar rules. My explanation in the documentation sucks, but I believe the examples help understand the process.
Leg's syntax extension is ad hoc at best; I only added the vararg and switch examples to demonstrate that they could be done. It's not hard to do, once you get the idea, but there are lots of little details you have be aware about to ensure the proper matching and capturing.
Leg seems to have made efforts toward providing a extensible interface for
customizing the grammar and actions. Much attention has been paid to this in
Metalua via gg/mlp, though further work should be done on this in LuaFish. I've
discussed with Fabien at some length on this topic, and he has strong opinions
in favor of the gg "extensible parser" in Metalua over PEG. A concern is that
extending the grammar by inserting custom PEG rules provides maybe *too much*
flexibility for its own good and not enough structure. For example, if two
people write language extensions, then there is little to ensure that two
extensions are compatible and can be used in the same code (a concern that gg
works to address).
I haven't looked into this very much, so I have no strong options about one or the other, but Leg's grammar extension API is definitely raw. I like gg's API, and when I first saw it, I originally thought that instead of exporting the grammar table directly, Leg could export an object which uses the grammar table underneath to do the heavy lifting. The user would mess only with the object, which would have a nice, clean public interface.
But I haven't done anything in this direction, and I probably won't for a while, so feel free to try it.
