Короче, как я это понимаю 'грубо' есть ряд проблем которые делают грамматику неоднозначной, эти неоднозначности вызывают проблемы редукции, просто взять и сделать грамматику детерминированной не выйдет, потому что даже такие базовые штуки как if else приоритет операторов ну и т.д. вызывают появление ambigues. Тоесть ну конечно в теории можно изобрести такую подграмматику, но практического толку от этого никакого потому что это будет подобием калькулятора который даже в скобочки не смог, поэтому и требуется велосипед ввиде правил резолва что описанны в ссылке выше. Тоесть я не к тому что совет плохой, я скорей к тому что путь тупиковый. В моем случае есть 2 варианта - плюнуть взять готовый парсер ну или написать патч в lalrpop. Есть еше вариант с экшенами который вроде сами ахо и ко описывают в пейпере

Хмм... я думал, что проблема с неоднозначными грамматиками — не техническая, разве нет?
Т.е. проблема в том, что "пользователи" (программисты на языке, заданном такой грамматикой) сами не будут знать, что значат их программы, грубо говоря. Т.е. эту проблему придётся решать, и ни один метод разбора тут не поможет.

Проблема решается очень просто: достаточно сказать пользователю, что код неоднозначен.

"У меня болит, когда я так делаю — а Вы так не делайте", да? ;)
Вы где-то видели применение такого подхода на практике?

Конечно, намного лучше, когда компилятор/интерпретатор сам догадывается, что программист имел в виду. 😉

Нет. Намного лучше, когда поведение компилятора/интерпретатора ожидаемо, а грамматика однозначна.

В свифте решили иначе. Он ругается, когда бинарные операции несравнимы.

Жаль его нельзя никак спроектировать как фреймверк какой или базу данных что бы можно было потом под другие языки использовать