thurston

A sure-fire way to beat a Ragel parser is to look ahead several characters and test the limited possibilities that are present when a language has literal strings like GET and POST. You can essentially fall back to extremely fast string searching algorithms in certain places.

Ragel assumes character-by-character parsing and it's difficult to generate fast code that looks ahead without running into buffer block boundaries. It could be done though.

You can also use character classes to reduce the number of tests. Ragel doesn't try to figure those out.

A few people have stopped by the mailing list wondering how much work it would be to add a python generator. You could send a few motivating words in their direction to increase the chances of it being worked on.

Ry's is faster. Ragel does pretty good and it gets you most of the way there when you need something that runs really fast, but it can't beat what a skilled programmer can do to optimize a parser.

That's awesome.

Correction: ragel is not bound to chars. It can consume integral numbers of any size up to long. The numbers do not need to be in arrays. They can be embedded in structures.

I'd like for DNSP implementations (which allow users to lay claim to a URI) to support OpenID in the sense that it is a provider of identities. It can't be a consumer though, since an OpenID identity cannot (necessarily) talk DSNP.

Parsing and translation.

You can define a full grammar for a language and embed actions in arbitrary places. It is compiled to a very fast DFA. Think of it as a yacc for regular languages.

Zed's advocacy for Ragel is really about using parser generators to implement internet-facing parsers.

Just a note on ragel: it can be used to create lexers, but that is not its distinguishing characteristic. It is a parser generator for regular languages.