Re: SableCC Thoughts Part II

[Dan Sandberg <dan@siliconpoetry.com>]

[Etienne referring to CUPS and CoCo parser generators]

> I know about both tools.  I know about these error-recovery method, yet
> I am far from convinced that they are in any way intuitive for the
> average compiler programmer.

Interesting.  I know you're busy now, but at some point when you have
more time I'd love to see an example of when the error-recovery
construct:

a = b |
    c |
    error eol;

introduces non-intuitive behavior.  I'm curious because the construct
seems very clean to me.  


> One of the fundamental objectives of SableCC is to simplify the desing,
> implementation, and maintenance of compilers/interpreters.
> 
> Most (if not all) existing "compiler compilers" (I prefer to say
> "compiler generators") provide ad-hoc tools to deal with difficult
> problems.  These tools are to SableCC what "C" is to "Java"; they let
> you shoot yourself in the foot without much of a warning.
> 
> The operator precedence, in CUP/YACC/Bison is useful, if you know
> exactly what you are doing when you use it.  The problem is that, unless
> you have perfectly understood how (LA)LR parsing tables work, and their
> relation to their grammar, you might be hiding unexpected grammar
> ambiguities (by solving the arbitrarily).  This means that your parser
> will be "accepting" a different language that the one you expect.  And
> you have no way of knowing that before you get a user of you compiler
> complaining about a strange bug (and even then, it might take you a
> while before you trace the bug to operator precedence in your grammar
> specification!).
> 
> Worse.  CUP/YACC/Bison let you "resolve" shift/reduce and reduce/reduce
> conflicts by reducing or shifting arbitrarily.  I know very few people
> that really undertand the implication of such a decision.  Last year, I
> even fixed a bug in a grammar written by a professor teaching a compiler
> course at a university in Denmark.  The grammar was using the "shift by
> default" shift/reduce conflict resolution of YACC.  The bug showed up
> when I tried to write a "pure LALR" version of the grammar for SableCC.
> 
> I am working on adding conflict resolution mechanisms into SableCC, but
> only "safe ones".  This implies specifying these thing differently.
> This is possible, and yields a powerful mechanism safely useable by
> novice compiler/interpreter programmers.  This is the direction in which
> I want to push SableCC.

Ok, I understand.  That does sound great.
 
> I am ready to allow some "unsafe" features in SableCC.  It's already the
> case. A very knowledgeable person can do almost anything by overriding
> the "filter" method.  But unlike the other tools, I want those features
> to be less accessible.

Ok, that make sense.
 
> I know that it is sometimes difficult to rewrite a grammar to eliminate
> conflicts.  But this price is small, when compared to getting a parser
> that you think parses a language, when in fact parsing another.

Are you certain it is always possible to rewrite a grammar to eliminate
the conflict?  I can rewrite the little grammer example I gave in a
previous message so it will be ACCEPTED without conflicts, but not
without causing the parse tree to lack the information I need to really
understand the language.

-Dan