Re: Remove useless associativity/precedence from parsers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove useless associativity/precedence from parsers
Date
Msg-id 16655.1558584035@sss.pgh.pa.us
Whole thread Raw
In response to Re: Remove useless associativity/precedence from parsers  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Remove useless associativity/precedence from parsers  (Robert Haas <robertmhaas@gmail.com>)
Re: Remove useless associativity/precedence from parsers  (Akim Demaille <akim@lrde.epita.fr>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Another thing is that it would be nice to have a better way of
> resolving conflicts than attaching precedence declarations.  Some
> problems can't be solved that way at all, and others can only be
> solved that way at the risk of unforeseen side effects.

Yeah, we've definitely found that resolving shift/reduce conflicts via
precedence declarations has more potential for surprising side-effects
than one would think.  It feels to me that there's something basically
wrong with that concept, or at least wrong with the way we've used it.
Some relevant commits: 670a6c7a2, 12b716457, 6fe27ca2f, and the
"x NOT-something y" hacks in commit c6b3c939b (that one has a whole bunch
of other cruft in it, so it might be hard to spot what I'm talking about).

> One possible
> idea is a way to mark a rule %weak, meaning that it should only be
> used if no non-%weak rule could apply.  I'm not sure if that would
> really be the best way, but it's one idea.  A more general version
> would be some kind of ability to give rules different strengths; in
> the case of a grammar conflict, the "stronger" rule would win.

Hmmm ... not apparent to me that that's really going to help.
Maybe it will, but it sounds like more likely it's just another
mechanism with not-as-obvious-as-you-thought side effects.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: nitpick about useless floating point division in gimme_edge_table
Next
From: Tom Lane
Date:
Subject: Re: Patch to fix write after end of array in hashed agg initialization