Re: Remove useless associativity/precedence from parsers

Поиск
Список
Период
Сортировка
От Akim Demaille
Тема Re: Remove useless associativity/precedence from parsers
Дата
Msg-id 50771E7F-1BB1-43BD-B785-C0234C51D369@lrde.epita.fr
обсуждение исходный текст
Ответ на Re: Remove useless associativity/precedence from parsers  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Remove useless associativity/precedence from parsers  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
Tom,

> Le 23 mai 2019 à 06:00, Tom Lane <tgl@sss.pgh.pa.us> a écrit :
>
> 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.

That's why in recent versions of Bison we also provide a means
to pure %expect directives on the rules themselves, to be more
precise about what happens.

> It feels to me that there's something basically
> wrong with that concept, or at least wrong with the way we've used it.

I'm trying to find means to scope the prec/assoc directives, because
they are too powerful, and that's dangerous.  This is also why I try
to remove the useless ones.

Some people don't trust assoc/prec directives at all and use only
unambiguous grammars.  But this can be very verbose...

I agree something is not so cool about these directives.  GLR parsers
have a clear concept of in-between-rules precedence (%dprec).  Something
similar for LR (hence fully static) would be nice, but it remains to
be invented.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Akim Demaille
Дата:
Сообщение: Re: Remove useless associativity/precedence from parsers
Следующее
От: David Fetter
Дата:
Сообщение: Re: Contribute - money