ПМСМ не совсем ясно в чём связанность/связываемость, я в основном в примерах указывал на логический результат выражений, но "логические выражения" занято... хотя не занято "логические обобщения" - указываем и на результат и на применимость к множествам.

Господа, я опять с извечными проблемами: parser generator vs. handwritten???
Я почитал плюсы и минусы, проблемы, всё вот это. Но пока всё равно на распутье.
С одной стороны, вроде как индустриальный стандарт это генераторы. Многие умеют в error recovery итд. Но они идут тяжело и надо инвестировать в умение писать граматики.
С другой стороны, как парсер вручную написать я знаю и можно начать хоть сейчас + его тоже многие используют.

Вопрос: стоит ли инвестировать в изучение какого-либо генератора и его использование? Или стоит начать с простого ручного парсера и постепенно его улучшать?
С ручным у меня есть опасения что его сложность можеть сильно возрасти по сравнению с использованием генератора.
С генератором есть опасения, что я уткнусь в какое-то ограничение, которое не позволит мне двигаться дальше))

Господа, я опять с извечными проблемами: parser generator vs. handwritten???
Я почитал плюсы и минусы, проблемы, всё вот это. Но пока всё равно на распутье.
С одной стороны, вроде как индустриальный стандарт это генераторы. Многие умеют в error recovery итд. Но они идут тяжело и надо инвестировать в умение писать граматики.
С другой стороны, как парсер вручную написать я знаю и можно начать хоть сейчас + его тоже многие используют.

Вопрос: стоит ли инвестировать в изучение какого-либо генератора и его использование? Или стоит начать с простого ручного парсера и постепенно его улучшать?
С ручным у меня есть опасения что его сложность можеть сильно возрасти по сравнению с использованием генератора.
С генератором есть опасения, что я уткнусь в какое-то ограничение, которое не позволит мне двигаться дальше))

> И могут ли на выбор повлиять свойста языка, который я хочу сделать?

Безусловно. В основном, "выбор" рукописных парсеров для C/C++ определяется тем, что грамматика у них "вычурная" и ни в какие ворота LL/LR не влазит. Лучшие так не делать.

Отсюда и обратная закономерность: выбор подхода повлияет на грамматику языка. Известный пример – Python, грамматика которого в существенной степени определялась ограничениями LL(1) парсера.

А как же их парсил gcc до перехода на recursive descent (я немного пытался поискать, но в mailing lists gcc мне лично как-то трудно ориентироваться), кстати?

А как же их парсил gcc до перехода на recursive descent (я немного пытался поискать, но в mailing lists gcc мне лично как-то трудно ориентироваться), кстати?

Я – без понятия. 🤷‍♀️

Кстати, по поводу https://t.me/CompilerDev/81329 , есть такой вопрос — какие компиляторы в области считаются "основными" и почему?
Т.е., например... По распространённости языка, который компилируется? Или по целевому языку (к примеру, всё, что не генерирует машинный код — "мимо")? Или по количеству работающих над ними (или рабочих мест)? Или по количеству "вкладываемых" туда оптимизаций и "продвинутых" технологий?

Я за транслит

В моей голове — это по распространенности языка и самого компилятора

со школьных времён привык к statement -> оператор, operator -> операция

"Распространённость" — это как много программистов его используют?
И интерпретаторы и т.п. — "мимо", я правильно понимаю?

Мне кажется, Вам стоит прочитать недавнее обсуждение, начиная где-то отсюда: https://t.me/CompilerDev/81239

Спасибо, почитал.
Пока прихожу к выводу, что от handwritten парсера я не умру и он позволит мне сделать «всё» что мне нужно будет

Господи, это было субъективное высказывание, основанное на небольшом наивном опыте

Да я же и не только Вас спрашиваю...
Мне просто интересно, почему у указаний на то, как работает gcc/clang и т.п., такой "вес". ;)
Я так понял, что это потому, что среди "компиляторщиков" они считаются важными/выдающимися... но почему?

Спасибо, почитал.
Пока прихожу к выводу, что от handwritten парсера я не умру и он позволит мне сделать «всё» что мне нужно будет