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

From Robert Haas
Subject Re: Remove useless associativity/precedence from parsers
Date
Msg-id CA+Tgmob1ZkqK49p6ALAJz_TRSkqqS-N4SxX662kix_qRctAUew@mail.gmail.com
Whole thread Raw
In response to Re: Remove useless associativity/precedence from parsers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, May 23, 2019 at 12:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > 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.

That's possible; I'm open to other ideas.  If you wanted to be really
explicit about it, you could have a way to stick an optional name on a
grammar rule, and a way to say that the current rule should lose to a
list of named other rules.

It seems pretty clear, though, that our use of %prec proves that we
can't just write a grammar that is intrinsically conflict-free; we
sometimes need to have conflicts and then tell the parser generator
which option to prefer.  And I think it's also pretty clear that %prec
is, for anything other than operator precedence, a horrible way of
doing that.  A method that was merely mediocre could still be a big
improvement over what we have available today.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: Minimal logical decoding on standbys
Next
From: Peter Eisentraut
Date:
Subject: Re: Fuzzy thinking in is_publishable_class