Why are parser tools rarely used in Ruby?

ruby-talk
1

Phil et al.:

I think I can have an operational lexer/parser ready for general
experimentation in about two weeks or so. It will be a DLL you can
dynamically link to and/or a LIB file that you can statically link to in C
or C++ (depending on how you compile it). The goal is to provide a 100% Ruby
1.7 compatible, general-purpose syntax lexer-parser and an API for
traversing the generated AST, whatever your purpose is - interpreting, code
analysis, compiling to C code, compiling to byte code, etc. It will be C
compatible so you could theoretically call it from Ruby/DL for basic
parsing, obviating the need to code in C/C++ for those C-sick types who get
queasy at the mere sight of declared variables, asterisks, ampersands and
squiggley braces.

Not sure about how it will stack up to Ruth; I haven’t seen that. Got a
link? I couldn’t find it in RAA doing a brain-dead “CTRL-F” search for
"Ruth".

– Bob Calco

%% -----Original Message-----
%% From: Phil Tomson [mailto:ptkwt@shell1.aracnet.com]
%% Sent: Tuesday, September 17, 2002 2:33 AM
%% To: ruby-talk ML
%% Subject: Re: Why are parser tools rarely used in ruby?
%%
%%
%% In article 001301c25dea$5dfbaae0$d501a8c0@TECHNO,

···

%% Rich Kilmer rich@infoether.com wrote:
%% >Just to put in a little plug for a friend…Bob Calco is actively
%% >working on a c-parser for Ruby code based on Matz’s parse.y file that
%% >detaches the Ruby source parsing from the Runtime. Its going to build
%% >c-structures of the parsed AST and will be usable by Ruby programs (to
%% >parse Ruby) examples of which are the FreeRIDE IDE for fast source
%% >parsing. It will also be useful for other languages that want to parse
%% >Ruby (through C).
%% >
%%
%% So we’ll be able to get the AST for the currently running program? Any
%% schedule for the initial release? Does Bob need any help? I’m thinking
%% this might be useful for Cardinal.
%%
%% BTW: Is this similar to Ruth which I belive is also based on Matz’
%% parse.y file?
%%
%% Phil
%%

2

In article NCEJJNLDMEJLEJHKNGNHKEIHEDAA.robert.calco@verizon.net,

Phil et al.:

I think I can have an operational lexer/parser ready for general
experimentation in about two weeks or so. It will be a DLL you can
dynamically link to and/or a LIB file that you can statically link to in C
or C++ (depending on how you compile it). The goal is to provide a 100% Ruby
1.7 compatible, general-purpose syntax lexer-parser and an API for
traversing the generated AST, whatever your purpose is - interpreting, code
analysis, compiling to C code, compiling to byte code, etc. It will be C
compatible so you could theoretically call it from Ruby/DL for basic
parsing, obviating the need to code in C/C++ for those C-sick types who get
queasy at the mere sight of declared variables, asterisks, ampersands and
squiggley braces.

Sounds good! I look forward to playing with it.

Not sure about how it will stack up to Ruth; I haven’t seen that. Got a
link? I couldn’t find it in RAA doing a brain-dead “CTRL-F” search for
“Ruth”.

From the readme

···

Bob Calco robert.calco@verizon.net wrote:

Author: Robert Feldt, feldt@ce.chalmers.se

What is it?

Ruby extension giving classes and functions to access Ruby internals.
Currently includes:

  • ruth/mri, Ruby::Interpreter.parse
    Gives a tree representing the internal parse tree used to execute a
    Ruby
    program.
  • ruth/mri, Ruby::Interpreter.method_body
    Returns the tree for the body of a method.

And a painfully incomplete:

  • ruth/parser, Ruby.parse
    Parse Ruby source code into an abstract syntax tree. Currently uses
    RubySchema from Mathieu Bouchard’s MetaRuby project to represent the
    AST’s.
    Its a cheato-RubyInRuby parser since it looks like one but actually uses
    Matz’s Ruby Interpreter’s parser and then simply transforms the output.
    Advantage of this is that it parses exactly the same programs as MRI
    parses
    (since it uses the same parser). Disadvantage is that it relies on C code,
    isn’t customizable etc.

Phil