Re: Remove useless associativity/precedence from parsers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Akim Demaille <akim(at)lrde(dot)epita(dot)fr>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Remove useless associativity/precedence from parsers
Date: 2019-05-23 04:00:35
Message-ID: 16655.1558584035@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-23 04:02:36 Re: Patch to fix write after end of array in hashed agg initialization
Previous Message Mark Dilger 2019-05-23 03:57:49 nitpick about useless floating point division in gimme_edge_table