Re: Markus' ruby-parser

On Mon, 14 Jan 2002, Mathieu Bouchard wrote:

> > * Lexer is pretty well tested but not all constructs in the language has
> > been tested with the parser so some bugs still there. What is needed is to
> > write some more tests for the parser (singletons for example).
> 
> 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?).

 > several equivalent ways of parsing some expressions. For
example, > semicolons parse to Body structures, which have no predefined
> associativity, and for which flattening has no effect. If two different
> parsers can give two slightly unequal - but equivalent - expressions, how
> can all parsers have common tests? Or maybe this is a non-issue and all
> parsers should give exactly the same output.
> 
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.

> > Matju and I have already discussed how the resolution of RubySchema
> > can actually be increased if one wants to (Plus = Expr.of(:+) for
> > example).
> 
> That would be Plus = M.of(:+), my mistake; also, a+b is
> M[LVar[:a],:+,[LVar[:b]],nil,nil] instead of Expr[Id["a"],:+,Id["b"]].
> 
> But the increased resolution would only would work with case-exprs,
> because Types in general only work with case-statements; you need Modules
> if you need decentralized dispatch. plus, case-exprs are slow, while
> method-dispatch is fast.
> 
Then we still need to solve the issue of resolution. Let me try and
summarize the pros and cons (correct me were I got it wrong):

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

With higher resolution "a+b" would be Plus[Id["a"], Id["b"]] while the
latter would be Call[Id["a"], "+", Id["b"], nil, nil] so no info is
lost ie. we can pretty-print them back to their original form etc. But
there are any more classes so harder to grasp etc.

I think ideally we should merge these approaches so that Plus is a
subclass of Call (or M in RubySchema) that specializes it. The parsers
should generate the highest resolution constructs but the user need only
see them at the lower-resolution level (since Plus is-a Call).

This is my current view. I'd appreciate if you point out any
flaws/omissions or have opinions what we should do. I've probably forgot
some of Matju's previous good motivations/explanations; sorry...

> > (and the deadline for my PhD project started coming really close...
> > ;-)).
> 
> How did it go?
> 
Still 6 weeks to go...

/Robert