freeride-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FR-devel] Nishio's Source Browser


From: Hal E. Fulton
Subject: Re: [FR-devel] Nishio's Source Browser
Date: Mon, 9 Sep 2002 18:28:49 -0500

----- Original Message ----- 
From: "Bob Calco" <address@hidden>
To: <address@hidden>
Sent: Monday, September 09, 2002 4:09 PM
Subject: RE: [FR-devel] Nishio's Source Browser

(snippage)

Bob, 

That's interesting and exciting. Comments below.

I guess my most important question, though, is this:
How mature is it and how functional at present? We'd
like to be able to distribute an early version of 
FR at the RubyConf.

Is your parser stable enough to be used in Nishio Mizuho's
class browser? Or maybe that's too much work to integrate
the two anyhow. What do you think?

> My goals are to create a lexer/parser DLL for Ruby that:
> 
> 1. is decoupled from the Object Runtime but 100% compatible with it
>    (in other words, Matz could decide to use it in the core distro
>    instead of the current highly coupled parser and everything
>    would work)

That's a wonderful idea, and I hope it's adopted.

One reason this is great is that it would be nice to have
a "canonical" Ruby parser usable by *any* piece of software
and have faith that it parses the same way Ruby does.

Backends could be: IDEs, debuggers, editors, irb-like tools,
RDoc-like tools, prettyprinters, lint-like tools, and more.

> 2. exposes an API for traversing the symbol table that is simple,
>    event-driven, and that follows the POLS.

That's great also. Have you considered a non-event-driven
model also? I.e., just a traversable tree? Just a thought.

> 3. compiles with each of the target compilers that can be used to
>    compile Ruby itself.

Yes, that's essential.

Good work, keep it coming.

Hal








reply via email to

[Prev in Thread] Current Thread [Next in Thread]