Re: [ANN] Leg v0.1

[David Manura <dm.lua@...>]

Hello Humberto,

Humberto S. N. dos Anjos writes:
> I am proud to announce the first release of Leg, a Lua library
> which offers a complete Lua 5.1 grammar and a small API for user
> manipulation. It uses LPeg extensively for pattern matching...

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 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 think it's obvious that many language features people want will not make it
into the minimalist Lua core, but there remains is significant interest in a
more extensive language.  The topic has come up at least three times this month:

  http://lua-users.org/wiki/LuaMacros
    -- Steve Donovan's macro facility based on token filters

  http://lua-users.org/lists/lua-l/2007-11/msg00014.html
    -- Asko Kauppi's syntax extensions via C++:

  http://lua-users.org/lists/lua-l/2007-10/msg00751.html
    -- "Lua is not skin deep" discussion.

Metalua and our other efforts could fill that void without incompatible forks of
the Lua core and difficult to maintain C patches.  Syntax extensions, static
code analysis, syntax highlighting, and code optimizations are all served by
tools to manipulate the language (see also http://lua-users.org/wiki/LuaGrammar ).

Note in the above "Lua is not skip deep" discussion the concerns about
"source-to-source" translations, which are currently used in Leg and LuaFish
when applied to syntax extension applications.