From: ptkwt@...1.aracnet.com (Phil Tomson)
Date: 2002-11-08T08:29:43+09:00
Subject: Re: [FR-devel] RE: bRuby? (Yet another Ruby parser)

In article <NCEJJNLDMEJLEJHKNGNHAEPJFDAA.robert.calco@verizon.net>,
Bob Calco <robert.calco@verizon.net> wrote:
>Phil:
>
>My parser will take the idea of separation from the runtime to its logical
>conclusion and provide a very flexible API for attaching the wires and plugs
>to whatever backend might need to walk the AST, for whatever purpose.
>
>I have in mind back ends like interpreters, VMs, debuggers, source browsers,
>etc. But the API will allow for different levels of depth in terms of
>inspecting the tree, so relatively simple utilities like a doc generator
>that works from comments only, and therefore that don't need all the bells
>and whistles can ignore the features they don't need and it will still work.
>
>In other words, my parser will be a generic lexing/parsing front end to any
>tool that expects source conforming to Ruby syntax for input. It will expose
>itself through a C/C++ API using standard calls so other languages that
>support cdecl like Delphi/Kylix can use the DLL/SO file for whatever
>purpose.
>
>Implementation wise, Tanaka Akira's approach, which I saw today for the
>first time and is found at
>
>http://cvs.m17n.org/cgi-bin/viewcvs/xmlize/?cvsroot=ruby
>
>is the closest to mine of those available (Ruth, Ripper), though Tanaka's
>goal is an XML representation of the code, which is somewhat different than
>mine.
>
>My goal is to have a parser with an API that easy enough to use so that
>Tanaka could create the XMLizer utility very quickly using Ruby DL for
>instance instead of having to do all the painful work Tanaka had to do (and
>did very well, I might add).
>
>Concern about duplication of effort is, I think, valid, but the evils
>thereof may be somewhat overrated. I would be happy to merge my efforts with
>anybody else, but I'd also be happy just having time to finish what I
>started working on myself. 

I don't believe that parallel projects are intrinsically evil, mostly I'm 
carping about the fact that there are so many 'half-finished' efforts.  So 
I'm thinking that more borrowing could be going on instead of reinvention 
in order to perhaps speed things up...

>I think having parallel efforts until such time
>as a consensus emerges about what is really needed and how it really ought
>to work is achieved is a good thing. But eventually these efforts converge
>as competing approaches are tried and the community gravitates toward a
>common goal. I'm pretty laizzez faire about such processes, but willing to
>work with anybody who is interested in doing what I'm doing.
>
>Phil, you more than anybody I think is moving the debate about a general
>parsing utility in the right direction - you've pinged me a few times to
>keep moving forward (and I appreciate that), and I might never had had the
>pleasure of noticing Tanaka's work, which gave me a few other ideas I hadn't
>considered even though overall we are taking a very similar approach toward
>somewhat different goals.
>

Yeah, I was aware of what you're working on, I asked the question here in 
this forum so that others who are working on the same sorts of things can 
see the answers ;-)

Sorry for being a nag on this issue, but I see having a Ruby parser as 
important to some projects I'm working on (Cardinal, RHDL) as well as for 
other projects (FreeRIDE, various documentation projects, and various 
Ruby-In-Ruby projects).

From my perspective I think we need two types of Ruby parsers:
1) A parser derived from Matz's parse.y file (as your project, Ripper and 
Ruth do).
2) A pure Ruby implementation (as Mark Leidl's (sp?) is - it's in the 
ruby cvs under ruby-parser/ ).


>So - thank you for getting the issue out in the open.

You're welcome.

So when are you going to have some code to post? ;-)

Phil