Hacker News Reader

Comment by Xion | Hacker News Reader

I'm quite flabbergasted seeing this:

https://github.com/charliesome/twostroke/blob/master/lib/two...

That is, a parser which is essentially coded by hand, with all token checking, saving and restoring parser's state, functions corresponding to non-terminating symbols of grammar etc.

Are there no good parsing libraries in Ruby (similar to Python's pyparsing or Haskell's Parsec), and could this have forced the author to code his parser from scratch?

View on HN

There's treetop, kpeg and a bunch of other stuff but I prefer writing my parsers by hand. Pretty much all that's missing from mine is semicolon insertion, but that's something I'm working to nut out.

Forced? I've written dozens of parsers, and personally I avoid parsing libraries like the plague - unless you're writing a really simple parser with few needs for error reporting and recovery, my experience is that parsing libraries usually end up being far more pain than they are worth.

Completely agreed. Once I got the hang of hand-writing parsers, I never looked back; they're higher-quality, generally faster, easier to write, and are easier to maintain than generated parsers.

My favorite compiler writer (dgc of mwc fame) says "Yacc makes the hard part of a compiler harder and the easy part easier".

Writing a parser by hand makes for a good exercise. No need to be flabbergasted!

I recently released a JavaScript parser for Ruby that uses Evan Phoenix's kpeg library: https://github.com/wycats/parsejs

Given that Ragel (http://www.complang.org/ragel/) can output Ruby code, it might be a great choice there.

Ragel just deals with FSMs, it can't generate a parser for a non-regular language.

You're right, thanks for the correction, I did not realize FSMs couldn't do that.

Sure there are, kpeg, citrus, treetop... Probably more I don't know about.

Reply on news.ycombinator.com