RE: [FR-devel] RE: bRuby? (Yet another Ruby parser)

[Bob Calco]

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 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.

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

Sincerely,

Bob Calco

%% -----Original Message-----
%% From: address@hidden
%% [mailto:address@hidden Behalf Of Curt Hibbs
%% Sent: Thursday, November 07, 2002 3:32 PM
%% To: address@hidden; Freeride-Devel
%% Subject: [FR-devel] RE: bRuby? (Yet another Ruby parser)
%%
%%
%% Phil Tomson wrote:
%% > >%%
%% > >%% All three of these seem to modify Matz's Ruby Yacc file
%% and create an
%% > >%% extension from the resulting c file.
%% >
%% >
%% >
%% > Yeah, I knew about Bob's project.
%% >
%% > I guess the point of my question is that there seem to be at least six
%% > projects out there that are essentially doing the same thing.
%% Aren't we
%% > duplicating a lot of effort?  Is there any way we can work
%% > together on one
%% > of these parsers and possibly get results quicker?
%% >
%% > Bob,
%% >
%% > Did you take a look at Ruth and Ripper before you started your project?
%% > If so how would you say what you are planning is different from those
%% > projects?
%% >
%% > Phil
%%
%% Bob give his own answer, but since I work closely with Bob
%% (others) on the
%% FreeRIDE and WxRuby projects I can tell you what I know.
%%
%% The original motivation for this parser was the FreeRIDE project. The
%% FreeRIDE IDE needs a fast and accurate Ruby parser to enable some of the
%% high-end stuff that we want to implement (we are currently using
%% ripper, but
%% it is using a modified version of the Ruby 1.6 grammar). The
%% goal here is to
%% put a wrapper around the actual parser that is used by the Ruby
%% interpreter.
%% The wrapper will have the kind of api that we need and will always be
%% accurate.
%%
%% Curt
%%
%%
%%
%% _______________________________________________
%% Freeride-devel mailing list
%% address@hidden
%% http://mail.nongnu.org/mailman/listinfo/freeride-devel
%%