|Question on %nonassoc-directive in LALR(1) parser generators email@example.com (2008-09-26)|
|Re: Question on %nonassoc-directive in LALR(1) parser generators firstname.lastname@example.org (email@example.com) (2008-09-27)|
|Re: Question on %nonassoc-directive in LALR(1) parser generators cfc@shell01.TheWorld.com (Chris F Clark) (2008-09-27)|
|Re: Question on %nonassoc-directive in LALR(1) parser generators firstname.lastname@example.org (Chris Dollin) (2008-09-29)|
|From:||Chris Dollin <email@example.com>|
|Date:||Mon, 29 Sep 2008 12:30:14 +0100|
|Posted-Date:||29 Sep 2008 07:37:49 EDT|
> 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:
> 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
'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
Search the comp.compilers archives again.