Re: Question on %nonassoc-directive in LALR(1) parser generators

mailings@jmksf.com wrote:




> I have a question about the %nonassoc-directive in LALR(1) parser
> generators like yacc, to influence the associativity and precedence of
> terminals. Yacc defines terminals attributed with %nonassoc as
> not-associative, so a grammar like:


(fx:snip)


> results in a parser that correctly accepts "x=x" but not
> "x=x=x". Running yacc (bison) in verbose mode also gives me the
> message that the state
>
> expr -> expr .'=' expr
> expr -> expr '=' expr .
>
> runs into an error because '=' is not associative.


I wonder if it's better to have the operator associate freely but then
to catch the issue in a subsequent pass or as the reductions happen.


I wonder this because rather than a generic unhelpful syntax error and
the likelihood of a cascade of help-the-parser-is-lost messages, you
can arrange to generate more user-oriented diagnostics.


If the `=` above is supposed to be an equality test, then the
message could be something like "equalities cannot be compared".
(An eyebrow-raising restriction that suggests the premise is false.)


If the `=` is supposed to be an assignment, then one of "assignments
do not deliver a value" or "an assignment cannot be assigned to".


(The reader may wordsmith the messages to taste.)


I think this is better for the user than the generic "unexpected
token" kind of message, although of course it does require more
work on the part of the parser-writer, so it is, As Usual, a
tradeoff.


--
'It changed the future .. and it changed us.' /Babylon 5/


Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England
[It's a swell idea but I think you'll find that it's a challenge to implement.
One of the worst things about LALR parsers is the difficulty in providing
useful syntax errors. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.