>>9967
>для создания генераторов лексического и синтаксического анализа
Не совсем уверен в нужности создания именно генераторов. Почему бы не образовывать правила в рантайме и парсить исходя из них?
Да и вообще, смотрел я как-то туториалы по этим флексам или бизонам, и не совсем понял, что это вообще такое. Это что-то странное и необъяснимое. Можно долго гадать над тем как мыслили люди в древности, какие у них были привычки, культура, менталитет, отношения между друг-другом. То есть флекс и бизон, они просто берут некоторый код, C-код и вставляют его в другой, генерируемый собой си-код? То есть это такой специализированный прерпоцессор. Мне так не нравится.

>Он вроде императивный
Наоборот же, пипарсинг и есть декларативный насколько можно. А вот я сейчас рядом открыл книгу, где рассказывается про флекс и бизон и вижу всякие императивный команды, ифы, вайлы, не понимаю, зачем всё это. Да и вообще, генерировать C и C++, для последующей их компиляции это как-то не очень. По-моему эти языки устарели, они только и годятся, что небольшие программки под ардуину писать, блинком помигать или по ESP8266 приконнектиться.

>декларативные регексы - это годно
Да, они декларативные, но меня не устраивает парочка фактов. Во-первых, в них вместо чётких и ясных команд используются одинкие символы: звёздочка, точка и что там ещё. Во-вторых, там есть выражения типа 0-9, a-z, но откуда программа знает, что после условного нуля идёт единица? А если я захочу, чтобы после него шла буква a? Не предусмотрели. Ладно, если бы это были отдельный константы, но константы надо использовать во время программирования, а не во время написания регекспов, ведь они это строки.
Где регекспы полезны, так это во всякие высокоуровневых аппликациях. Например, при поиске названия файла в файловом менеджере. Мне было бы очень хорошо, если бы я в pcmanfm мог ввести в поиск image*ko*.png, чтобы, например, найти все .png файлы, начинающиеся на image и внутри них есть ko (koshka, kot). А в программировании не надо.

>Если правильно помню, парсер на pyparsing парсит код лайси и переводит его в байт-код llvm.
Твоя инфа устарела, теперь я использую не pyparsing, а самописный dapapy (на питоне), прототип библиотеки dapa (для Лайси). Да, в конце он переводит в LLVM, но перед этим в лайси-байткод (для которого пока нет формата, только программное представление).
pyparsing не смог справиться с препроцессированием, а в dapapy есть больше возможностей, но и управляться с ним сложнее. Например, в dapapy опцинально наличие вайтспейсов. Вайтспейсы это токены, которые мусор и они просто пропускаются. То есть, когда человек пишет на языках программирования, разметки, он пишет много мусора — ' ' '\n' '\t' и всё такое. И вот вайтспейсы (в отличие, например, от "литералов", схожих по свойствам с ними) наследуются другими токенами, дочерними в правиле order (переопределяется опертором +). А для препроцессинга я специально в некоторых местах указал, что вайтспейсы не должны наследоваться. Для чего это нужно не помню, но теперь препроцессинг парсится декларативно, а не императивно.
И вообще, я ненавиажу императивно парсить что-либо. Помню, когда только начинал писать Icolaisi на Си, я как начал через циклы что-то там перебирать и офигел с этого. Потом узнал о пипарсинг и понеслось. Но ведь я продолжаю императивно парсить, в некоторых проектах, например, файлы ресурсов. В данном случае эти файлы это просто набор из всяких разных полей и включает в себя дополнительно картинки, аудио, 3D-модельки и другие файлы. И вот делаю я это на C++ и там мне приходится парсить императивно. А ведь на Лайси с dapa можно было бы написать что-то типа resources = int32 + numbered(token=-1,image) + int32 + numbered(token=-1,audio), ну ты понял и оно б само всё спарсилось, а дополниительные функции загрузили бы картинки, 3D-модельки, аудио в vp (void* в Лайси). И всё без вайтспейсов, так как формат бинарный.
...