Здравствуйте, Marty, Вы писали:

M>Гвидо там же говорит, что у него есть свой офигенский лексер, который он не хочет выкидывать.
Где вы там такое нашли? Всё, что там есть — длинное перечисление проблем в существующем парсере, как объяснение его интереса к PEG.

M>Я в такой же ситуации. Вот и всё. Для разминки думаю набросать пару языков на ручном рекурсивном спуске с использованием своего "лексера", а там дальше видно будет.
Кто ж вам запретит, делайте.
Меня собственно запиливание ручного рекурсивного спуска не интересует уже очень давно.
Интересует как можно более компактное решение типовых проблем современных парсеров:
— внятная диагностика синтаксических ошибок (у PEG с этим всё очень хорошо)
— внятная поддержка инкрементального парсинга (у PEG с этим всё очень хорошо; неплохо бы ещё автоматизировать и следующие стадии — скажем, корректировка таблиц имён и связанных с ними референсов без полного повтора семантического анализа, но это уже не про грамматики)
— внятная поддержка отката после ошибок (у PEG с этим всё неплохо — есть теоретические наработки, но не воплощены на практике).

Делать всё это вручную и каждый раз с нуля как-то не очень хочется.

M>Packet Diagram выглядит хорошим кандидатом, мне как раз надо как-то по-простому описать кастомную раскладку памяти в прошивке, чтобы её не компилятор генерил, а я своей тулзой (хочу прошить во флешку инфу по железке раз и навсегда, а потом бутлоадер будет проверять, соответствует ли фирмварь хардварной ревизии), и этот кусочек прошивки хочу описать в виде Packet Diagram, а тулзе значения переменных отдавать, и она бы HEX генерила по такому описанию. Должно получится на имеющемся быстро и не слишком сложно
Ну, тут формат примитивный, для него PEG делается в несколько строчек.

M>Вы (ничего, что я на Вы?) сами же говорите, что это полное говно, нет?
Ну да, а чему это противоречит? Неговна незавезли.
M>И что там двухстадийная раскраска, и первая фаза на регэксах? У меня работает гораздо быстрее регэксов
:sigh: Что именно работает быстрее регекспов?
Предположим, что вы придумали новый язык описания чего-нибудь. Неважно — программного кода, расположения прошивок в памяти, диаграмм, или дерева эффектов в фильме.
Современные пользователи избалованы — они хотят не просто тул, который можно вызывать из командной строки с разнообразными флагами.
Они хотят полноценный интерактивный экспириенс — чтобы файлики эти можно было открывать там же, где они редактируют остальной контент; чтобы там раскраска синтаксиса работала, сворачивание регионов, навигация по коду, чтоб ошибки были и в списке project problems, и подчёркнуты прямо в редакторе, чтобы были quick fixes для этих ошибок, чтобы работал автокомплит, всякие go to definition и find all usages. И чтобы всё это — прямо на лету, интерактивно, и без please wait for project reindexing.
Можно начать колхозить свою IDE с блэкджеком и С++, но это — очень большая работа. В современной IDE уже наколбашено огромное количество функций, как встроенных, так и при помощи плагинов.
Даже если отказаться от собственно интегрированности, то даже "простой редактор кода" — это уже овердофига всяких фич, которые дорого писать с нуля. Поэтому берут за основу, скажем, тот же Monaco.
И вот теперь возникает вопрос — а как этому редактору обмениваться с вашим супербыстрым лексером? Ах, если бы он был написан на чистых плюсах, то ваш код можно было бы добавить к коду этого редактора, и собрать всё одним компилятором. Но нет — не написан он на плюсах. Поэтому поток маркеров стиля вы будете ему отдавать в виде JSON. И в итоге сколько бы вы времени ни сэкономили на переходах в конечном автомате, это просто потеряется на фоне стоимости сериализации/десериализации в JSON.
Именно поэтому современные IDE красят текст регекспами. Регекспы грузятся в память основного редактора, компилируются там, и работают приемлемо быстро, не создавая гигабайтного трафика между редактором и LSP.

M>Ну, надо будет плагин-парсер запилить для интерполированных строк, как и для любых нетривиальных литералов
Отож. Любую проблему можно решить допиливанием костыля для костыля. Кроме проблемы избытка костылей.

M>Ну, если бы был хороший инструмент, который позволяет не размазывать, то я бы на него посмотрел. Может и приду к чему-то такому, может сам запилю. Пока ничего не нравится
Хороший инструмент — это PEG.

M>Вы, наверное, забыли тут вставить
Нет, зачем. Я искренне рад за вас — сам люблю баловаться всякими велосипедами. Вот, в нынешнем проекте я из любви к искусству запилил VS Code extension с парсером и семантическим анализатором для нашего языка программирования. Пока остальная команда делала компилятор по-старинке — через bison и yacc. Когда есть возможность сравнить — сразу видно, насколько PEG выигрывает у классики.
Очень много тавтологичного бойлерплейта требуется для написания парсера традиционным методом.