# RedParse 0.8.4 Released

**URL:** <https://www.ruby-forum.com/t/redparse-0-8-4-released/181033>\
**Category:** Ruby\
**Created:** [January 4, 2010, 8:42am UTC](https://www.ruby-forum.com/t/redparse-0-8-4-released/181033 "2010-01-04T08:42:49Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![pandemic](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/8491ac/32.png) [@pandemic](https://www.ruby-forum.com/u/pandemic)\
**Post date:** [January 4, 2010, 8:42am UTC](https://www.ruby-forum.com/t/redparse-0-8-4-released/181033/1 "2010-01-04T08:42:49Z")

</div>

RedParse version 0.8.4 has been released!

- [GitHub - coatl/redparse: RedParse is a ruby parser written in pure ruby.](http://github.com/coatl/redparse)

RedParse is a ruby parser written in pure ruby. Instead of YACC or  
ANTLR, it’s parse tool is a home-brewed “compiler-interpreter”. (The  
tool is LALR(1)-equivalent and the ‘parse language’ is pretty nice,  
even in it’s current crude form.)

My intent is to have a completely correct parser for ruby, in 100%  
ruby. Currently, RedParse can parse all known ruby 1.8 constructions  
correctly. There might be some problems with unparsing or otherwise  
working with texts in a character set other than ascii. Some of the  
new ruby 1.9 constructions are supported in 1.9 mode. For more  
details on known problems, see below.

== Installation:  
Type this to install the gem:  
gem install redparse  
Or, download the tarball from rubyforge:  
[http://rubyforge.org/frs/download.php/68399/redparse-0.8.4.tar.gz](http://rubyforge.org/frs/download.php/68399/redparse-0.8.4.tar.gz)

== Benefits:

- Pure ruby, through and through. No part is written in C, YACC,  
ANTLR, lisp, assembly, intercal, befunge or any other language  
except ruby.
- Pretty AST trees (at least, I think so).
- AST trees closely mirror the actual structure of source code.
- unparser is built in
- ParseTree format output too, if you want that.
- Did I mention that there’s no YACC at all? YACC grammars are  
notoriously difficult to modify, (I’ve never successfully done it)  
but I’ve found it easy, at times even pleasant to modify the parse  
rules of this grammar as necessary.
- Relatively small parser: 70 rules in 240 lines  
(vs (by my count) 320 rules in 2200 lines for MRI 1.8.7. This is  
by no means a fair comparison, tho, since RubyLexer does a lot  
more than MRI’s lexer, and MRI’s 2200 lines include its  
actions (which occupy somewhere under 3100 lines in RedParse).  
Also, what is a rule? I counted most things which required a  
separate action in MRI’s parser, I’m not sure if that’s fair.  
On the other hand, RedParse rules require no separate actions  
anywhere.In the end, I still think RedParse is still much easier to  
understand than MRI’s parse.y.)
- “loosey-goosey” parser happily parses many expressions which normal  
ruby considers errors.

== Drawbacks:

- Pathetically, ridiculously slow (ok, compiler-compilers are hard…)
- Error handling is very minimal right now.
- No warnings at all.
- Unit test takes a fairly long time.
- Lots of warnings printed during unit test.
- Debugging parse rules is not straightforward.
- Incomplete support for ruby 1.9.
- “loosey-goosey” parser happily parses many expressions which normal  
ruby considers errors.

== Known problems with the parser:

- Encoding of the input is not stored anywhere in resulting parse tree.
- Ascii, binary, utf-8, and euc encodings are supported, but sjis is  
not.

== Known problems with the unparser:

- On unparse, here documents are converted into regular strings. For the  
most  
part, these are exactly equivalent to the original. However, whatever  
tokens  
appeared between the here document header and body will now show up on  
a  
different line. If one of those tokens was **LINE** , it will have a  
different value in the unparsed code than it had originally.
- some floating-point literals don’t survive parse/unparse roundtrip  
intact,  
due to bugs in MRI 1.8’s Float#to\_s/String#to\_f.
- unparsing of trees whose input was in a character set other than ascii  
may  
not work.

== Known problems with ParseTree creator

- Major:
  - converting non-ascii encoded parsetrees to ParseTree format doesn’t  
work

- Minor:
  - :begin is not always emitted in the same places as ParseTree does:
    - return begin; f; end

  - string nodes don’t always come out the same way as in ParseTree…  
but what I emit is equivalent.
    - %W"is #{“Slim #{2?“W”:“S”}”}#{xx}."

  - silly empty case nodes aren’t always optimized to nop like in  
ParseTree.

== Changes:

### 0.8.4 / 21dec2009

- 5 Major Enhancements:

- 18 Minor Enhancements:

- 18 Bugfixes:

- 9 Changes To Tests: