Re: Remove useless associativity/precedence from parsers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 13:10:44
Message-ID: CA+Tgmob1ZkqK49p6ALAJz_TRSkqqS-N4SxX662kix_qRctAUew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 23, 2019 at 12:00 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-05-23 13:13:00 Re: Fuzzy thinking in is_publishable_class
Previous Message Peter Eisentraut 2019-05-23 13:08:37 Re: Refresh Publication takes hours and doesn´t finish