Ratings and Reviews
Community Rating
Average Rating: 4.0/5.0Number of Ratings: 1Number of Reviews: 1
My Review of racc |
||
| You have not rated or reviewed this project.Click below to rate/review. | My Rating: | |
| New Review | ||
Most Helpful Reviews
Having suffered from bad performance of a TDP4R-based parser, I turned to racc to see if performance could be improved. Since racc generates LALR(1) parsers, I expected much better performance than I got with the backtracking recursive descent parsers you can write with TDP4R.
This expectation was correct - the parser was a lot faster. I had used yacc in C projects before, and I really liked how familiar racc feels! I got started quickly and managed to convert the parser easily. The parser's code size is comparable to the one I wrote with TDP4R, which kind of surprised me since you can do neat things with higher-order functions, while the racc parser has to be very straightforward, BNF-style.
The main disadvantage of using racc was that racc requires an edit-compile-test cycle, something that can really slow down your development process. TDP4R is pure ruby and does not require any preprocessing. Another disadvantage is that because it looks and feels so much like yacc, you're programming in an entirely different language that is not Ruby.
I really liked the way racc provides feedback about rule conflicts; it helped me detect and get rid of a superfluous rule (reduce/reduce conflict) which might also have been the cause of *some* slowdown in my original parser. Another neat feature is the debugging output log it can produce, which contains all the rules and states the parser knows about. It takes some getting used to and it's hard to grok the output, but it's very helpful even if you don't fully understand everything. And there's even a way to automatically get debugging output from a working parser while it is analysing its input.
I also briefly tried out Treetop, but didn't like it. It also requires compilation, is an extra dependency (the racc runtime ships with plain Ruby) and its syntax tree objects are not very convenient - it's much nicer to just return the final data structure straight from the parser.
I still like TDP4R for its ability to quickly hammer out a parser, but I'd certainly consider using racc from the start in a project where I knew parsing could be a major bottleneck. If I wasn't sure, I might use either; it's easy to do some prototyping in TDP4R and then convert the parser to racc. Just be careful not to rely on higher-order functions or dynamic combinators :)
Most Recent Reviews
Having suffered from bad performance of a TDP4R-based parser, I turned to racc to see if performance could be improved. Since racc generates LALR(1) parsers, I expected much better performance than I got with the backtracking recursive descent parsers you can write with TDP4R.
This expectation was correct - the parser was a lot faster. I had used yacc in C projects before, and I really liked how familiar racc feels! I got started quickly and managed to convert the parser easily. The parser's code size is comparable to the one I wrote with TDP4R, which kind of surprised me since you can do neat things with higher-order functions, while the racc parser has to be very straightforward, BNF-style.
The main disadvantage of using racc was that racc requires an edit-compile-test cycle, something that can really slow down your development process. TDP4R is pure ruby and does not require any preprocessing. Another disadvantage is that because it looks and feels so much like yacc, you're programming in an entirely different language that is not Ruby.
I really liked the way racc provides feedback about rule conflicts; it helped me detect and get rid of a superfluous rule (reduce/reduce conflict) which might also have been the cause of *some* slowdown in my original parser. Another neat feature is the debugging output log it can produce, which contains all the rules and states the parser knows about. It takes some getting used to and it's hard to grok the output, but it's very helpful even if you don't fully understand everything. And there's even a way to automatically get debugging output from a working parser while it is analysing its input.
I also briefly tried out Treetop, but didn't like it. It also requires compilation, is an extra dependency (the racc runtime ships with plain Ruby) and its syntax tree objects are not very convenient - it's much nicer to just return the final data structure straight from the parser.
I still like TDP4R for its ability to quickly hammer out a parser, but I'd certainly consider using racc from the start in a project where I knew parsing could be a major bottleneck. If I wasn't sure, I might use either; it's easy to do some prototyping in TDP4R and then convert the parser to racc. Just be careful not to rely on higher-order functions or dynamic combinators :)