From: Robert Feldt <feldt@...>
Date: 2002-01-16T19:59:18+09:00
Subject: Re: Markus' ruby-parser

On Wed, 16 Jan 2002, Mathieu Bouchard wrote:

> On Mon, 14 Jan 2002, Robert Feldt wrote:
> > On Mon, 14 Jan 2002, Mathieu Bouchard wrote:
> > > How about a shareable test suite ? The main issue I see is there are
> > Yes, that would be nice. Me and Rich Kilmer (who wrote some of the
> > tests) used RubyUnit while Marcus used a home-grown variant (based on some
> > of your stuff?).
> 
> It should be easy to convert everything to RubyUnit. I can take care of
> that the day I finally take the time to learn RubyUnit.
> 
Great!

Check out Markus tests and the ones in 

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rockit/src/examples/ruby/tests/

> > IMHO, we should strive for one parse for each program but it won't happen
> > until we have a common AST representation so we need to start there.
> 
> I meant even supposing that we agree on a common AST representation...
> Some things may happen depending on what degree of commonality there
> is. There is nothing preventing a RubySchema parser from introducing
> slight divergences like unneccessary Body[[x]] instead of just x in some
> places, etc.
> 
Ok, I think it would be unfortunate. If we strive for a common test I
think it should only allow one parse for each construct. If its not easily
done it should at least highlight the differences (so its
deterministic).

> The main benefit with having few but general constructs (low
> > resolution) is that there are fewer classes that you need to learn and
> > handle when extending etc. The drawback is that you may need to "parse
> > once more" ie. decide what kind of method call you have based on the
> > method id and arguments etc. Since the lower resolution implies more
> > general classes you have also lost information ie. was it written "a+b" or
> > "a.+(b)".
> 
> True. I may add BinOp (or "Op2") to RubySchema while keeping it out of
> MicroRubySchema; this is because the former schema has a fidelity
> requirement (and the latter hasn't)
> 
I like the idea of splitting it into several layers of different
resolution. If its possible to do it fully in a class hierarchy so that
BinOp really inherits M (which I think is a bit too non-descriptive; any
chance we can find a slightly more descriptive one that is not
meaningless?) that would probably solve it. But don'tyou agree that the
RubyInRuby parsers should generate schemas/terms/trees at the highest
resolution by default?

> I don't want to go to high resolution because it will flood the list of
> RubySchema Forms (there are already 61 of them). I don't envision much
> code that will work on Plus expressions: there will be all kinds of
> software working at very-low ("Form") and low/medium resolutions, but the
> Plus expressions will be limited quite specifically to: Optimising
> Compilers That Use Type Inference Or Declarations And Lots Of Smart
> Inlining To The Point It's As Fast As C. Correct me if i'm wrong.
> 
No that was the application I had in mind... :-)

Its probably a good point although I'm not sure about it (for example I
think pretty-printing'/formatting Ruby code might be an important
application and it will need the highest possible resolution as not to
alter the code more than necessary).

> > > > (and the deadline for my PhD project started coming really close...
> > > > ;-)).
> > Still 6 weeks to go...
> 
> courage!
> 
Thanks!

/Robert