|User friendly compiler-compiler tools firstname.lastname@example.org.OZ.AU (1995-10-14)|
|Re: User friendly compiler-compiler tools [comp.compilers #7671] email@example.com (1995-10-23)|
|Re: User friendly compiler-compiler tools firstname.lastname@example.org.OZ.AU (Fergus Henderson) (1995-11-09)|
|From:||email@example.com (Anton Ertl)|
|Date:||Mon, 23 Oct 1995 22:31:33 GMT|
|> [re building expression grammars]
|> > If you think it's necessary, add a few rules for implicit
|> > parenthesizing; when in doubt, require explicit parenthesizing.
|> Current operator-precedence parser generator tools such as yacc make
|> this unnecessarily difficult, because they require a total ordering of
|> operator precedences. Future such tools should allow a partial ordering.
If I remember my math education, partial ordering implies
transitivity. I.e., by stating explicit precedences like
'+' < '='
'=' < '&&'
you would get an implicit precedence
'+' < '&&'
which I did not learn in school and is not intuitive to everyone; in
other word, this precedence is probably not a good idea.
As long as there are only a few independent cases, normal BNF is nice
enough. You can simply add the rules for implicit parenthesizing to
the 'expr' rules in the grammar above.
E.g., for the precedence '=' < '&&' (without the associativity of '&&')
expr: expr1 < expr1 && expr1
expr: expr1 && expr1 < expr1
expr: expr1 < expr1 && expr1 < expr1
We can of course apply some factoring and get
expr: comparison && comparison
comparison: expr1 < expr1
As soon as the cases interact, things become more complex: The
classical hierarchical scheme with implied transitive precedences has
to be avoided. There also is the problem of LALR (or LL) conflicts.
M. Anton Ertl
Return to the
Search the comp.compilers archives again.