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

Если выкинуть борроу чеккер (мы же про парсеры), то не сложнее, а может и проще. Вот тут пишут компилятор раста на c++ https://github.com/thepowersgang/mrustc

Вот их парсер, 2300 строк https://github.com/thepowersgang/mrustc/blob/master/src/parse/root.cpp

Не, OGR это overlay graph representation

Это по сути ядро компилятора, если его оторвать то останется только парсер и и транслятор

Я погуглил, мне на ГИСы ссылку выдало. В контексте вашей реплики я понял, что вы про грамматику си vs раст.

Не, это я к тому написал что если на си у меня в одну каску такой убогий функционал занял столько времени то если лепить огр в котором все начиная от скоуп графа заканчивая всякими мелочами плюс ещё это ретпоактив структура

Займет ну примерно до mvp чистым временем от полугода

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

Так вы же исследовали разные подходы, а не просто брали и руками писали этот парсер, понятно, что на это нужно больше времени, но и в результате получается не только код, но и какие-то знания.

Ну это понятно, но и там придеться исследовать.

О, интересно, спасибо.

По такому же принципу существует для с/с++ проект

Особенность в том что это retroactive это раз, второе что важно данные абстрактны, ну тоесть к примеру нам не нужно хранить все типы но мы вполне может сделать запрос к типу выражения тоесть тип выражения будет computated priorities, вообще это почти графовая бд

Удобно можно сделать плагинацию, ещё как вариант можно bx проложить напрямую к ide, тоесть весим лейбл специальный на ноду, значение отражается прямиком в коде, изменяем АСТ оно изменяет текст в коде ну и тд

На самом деле я вот это и предлагал как последний версию макросов

АСТ чем плохо у нас нет семантического анализа, нельзя спросить у типа что он такое или куда ведёт гоу ту, мы не можем генерировать код заранее зная что он будет валидным, нам приходиться проверять это в конце при компиляции, это нарушает dry ну и тд плагины компиляции тоже не очень, они опираются на какое то жиденькое апи ну и тд