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

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

Там цикл статей, во второй статье:

Токенизация Python достаточно сложна, поэтому я не хочу реализовывать её на правилах PEG. Например, вы должны отслеживать отступы (для этого требуется стек внутри токенизатора); интересна также и обработка новых строк в Python (они значимы, кроме заключенных в соответствующие скобки). Многие типы строк также вызывают некоторую сложность. Короче говоря, у меня нет никаких претензий к уже существующему токенизатору Python, поэтому я хочу оставить его как есть. Кстати, у CPython есть два токенизатора: внутренний, который используется парсером, он написан на C, и стандартный библиотечный, который является точной копией, реализованной на чистом Python. Это пригодится в моём проекте.

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

Да, это всё очень замечательно, кто же спорит


S>Ну, тут формат примитивный, для него PEG делается в несколько строчек.

Можно будет сравнить, если вам не лень будет этим заняться. Я, когда запилю, напомню, на таком простом примере наверное не сложно будет уделать рукопашный парсер?


M>>Вы (ничего, что я на Вы?) сами же говорите, что это полное говно, нет?
S>Ну да, а чему это противоречит? Неговна незавезли.

Не говно — это когда функционал LSP доступен не через пайп, а через inproc плагин.


M>>И что там двухстадийная раскраска, и первая фаза на регэксах? У меня работает гораздо быстрее регэксов
S>:sigh: Что именно работает быстрее регекспов?

Мой токенизатор.


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

Тут надо разбираться, как сделать плагин для какой-нибудь IDE, это самое сложное. У меня вообще в тудушке есть пункт собрать некоторые свои плюсовые проекты в вебассемблю. Может появится побочный эффект, что я смогу на плюсиках делать плагины для ВСКода, но не факт.


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

Не костыля, а плагина


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

А насколько он хорош для плюсов?


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

bison и yacc

Вы хотели сказать, наверное, lex+yacc/flex+bison?

Я когда-то flex+bison тыкал, тоже не помню для чего, может те же плюсики раскрашивал. Это ужасно