ruby_parser (RP) is a ruby parser written in pure ruby (utilizing racc--which does by default use a C extension). RP's output is the same as ParseTree's output: s-expressions using ruby's arrays and base types.
FEATURES/PROBLEMS:
- Pure ruby, no compiles.
- Incredibly simple interface.
- Output is 100% equivalent to ParseTree.
- Can utilize PT's SexpProcessor and UnifiedRuby for language processing.
- Known Issue: Speed sucks currently. 5500 tests currently run in 21 min.
- Known Issue: Code is waaay ugly. Port of a port. Not my fault. Will fix RSN.
- Known Issue: I don't currently support newline nodes.
- Known Issue: Totally awesome.
- Known Issue: dasgn_curr decls can be out of order from ParseTree's.
- TODO: Add comment nodes.
SYNOPSIS:
RubyParser.new.parse "1+1"
# => s(:call, s(:lit, 1), :+, s(:array, s(:lit, 1)))
Changes:
1.0.0 / 2007-12-20
1 major enhancement
- Birthday!
Hey Ryan, you probably don't remember me but I've been to Seattle.rb a few times over the years. I wanted to let you know about my latest project Gazelle (http://www.reverberate.org/gazelle/) -- it's a parsing system that's intended to be a big improvement over tools like Bison or Racc.
I'd love for it to parse Ruby eventually. It's not ready for that yet, but when it is, I'd love to use your work here (or even work with you, if you're interested) to make that happen. The benefit of using Gazelle over writing this in Ruby (as you have done) is that the parser would be much, much faster (likely 10x, based on my experience writing comparable parsers in Ruby and C), and it could be used from any programming language (instead of just from Ruby).
You say it's a port-of-a-port -- what is it ported from?
Cheers, Josh
Hi Josh,
1) ruby_parser is going to stick to pure ruby solutions as best it can. I realize racc has a C extension, but it also has a pure ruby version of those methods. Also, it ships with ruby so even if it were all C, it'd still be able to be considered "native" as far as I'm concerned. We'll probably leave racc behind for a better parser, but even that will be pure ruby (probably treetop or an ometa port).
2) it is a port of jruby's parser (tho loooong diverged) which is a port of cruby's parser. Basically always sticking to the yacc family.
Out of curiosity, why is pure ruby a requirement? We're engineers, so best tool for the job, right? What if a Gazelle version of your parser was 10x the speed, 1/10th the code size, and could give you output in the format you use now. Would you still pass? If so, why?