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
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 |