[racket] pre-announcement for ragg. Request for comments and suggestions

From: Greg Hendershott (greghendershott at gmail.com)
Date: Fri Jan 4 17:05:03 EST 2013

This looks great!

> Preliminary documentation can be found at
> http://hashcollision.org/ragg.  I'd like feedback on what obvious
> functionality I'm missing from the system.  As far as I know, the huge
> gaping weakness is a lack of a story about tokenization, which I'm
> still trying to figure out ....

Could it work with parser-tools/lex?

Although actually I found parser-tools/lex to be more confusing than
paser-tools/yacc. I'd be interested in an alternative to
parser-tools/lex, as well.

(I say that as someone whose total lifetime experience with lexers and
parsers is with Racket's parser-tools. Given that background -- i.e.
no background at all -- I was expecting/hoping lex would use "normal"
regular expressions. I was able to use lex-sre, it just took me longer
to do what I wanted.)

On Thu, Jan 3, 2013 at 11:42 PM, Danny Yoo <dyoo at hashcollision.org> wrote:
>
> Hi everyone,
>
> I've been developing yet another parser generator generator framework
> for Racket.  Since "yapps" is already taken by another project, I'm
> calling this thing "ragg", for Racket AST Generator Generator.
>
> ragg is a parsing framework with the design goal to be easy to use. It
> includes the following features:
>
> * It provides a #lang for writing extended BNF grammars. A module
> written in #lang ragg automatically generates a parser. The output of
> this parser tries to follow HTDP doctrine; the structure of the
> grammar informs the structure of the Racket syntax objects it
> generates.
>
> * The language uses a few conventions to simplify the expression of
> grammars. The first rule in the grammar is automatically assumed to be
> the starting production. Identifiers in uppercase are assumed to
> represent terminal tokens, and are otherwise the names of
> nonterminals.
>
> * Tokenizers can be developed completely independently of parsers.
> ragg takes a liberal view on tokens: they can be strings, symbols, or
> instances constructed with the token function in ragg/support.
> Furthermore, tokens can optionally provide location: if tokens provide
> location, the generated syntax objects will as well.
>
> * The underlying parser should be able to handle ambiguous grammars.
>
> It's almost ready for release.  I'm in the middle of polishing ragg.
> Preliminary documentation can be found at
> http://hashcollision.org/ragg.  I'd like feedback on what obvious
> functionality I'm missing from the system.  As far as I know, the huge
> gaping weakness is a lack of a story about tokenization, which I'm
> still trying to figure out, and for this first release, I think I will
> need to skip it.  But since I want to make this Pretty Good (as
> Insanely Great is probably trademarked), I'd love to hear from other
> people what they need from a framework like this.
>
>
> Hope this helps, and happy new year!
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users

Posted on the users mailing list.