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


S>>>Ну, тут формат примитивный, для него PEG делается в несколько строчек.
M>>Можно будет сравнить, если вам не лень будет этим заняться. Я, когда запилю, напомню, на таком простом примере наверное не сложно будет уделать рукопашный парсер?
S>Что значит "уделать"? Опередить по компактности и читаемости кода — 100%.

Я пока не очень разобрался, как всё это работает в конкретных инструментах, но наверное на каждое правило должно быть навешено какое-то действие, типа, добавить элемент в AST. Можно считать, что код по навешиванию действий в PEG варианте не входит в парсер, а во втором варианте считать наоборот


M>>Не говно — это когда функционал LSP доступен не через пайп, а через inproc плагин.
S>Ну так его-то и не завезли. Собственно, за систему inproc-плагинов люди и не любили старую студию.

То есть, inproc-плагины — это говно, а по пайпу туда-сюда гонять джейсон — это офигенно?


M>>Мой токенизатор.
S>При отдаче результата в dev>null? Или он у вас там порождает стилизированный HTML?

Не очень понял. Мой токенизатор может порождать стилизированный HTML, я уже приводил этот пример. И я могу без проблем какому-то хосту отдавать информацию, что и с какой позиции надо красить каким стилем.


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

Это интересно, но не на столько, чтобы я кинулся сейчас сразу искать информацию на эту тему. Если есть под рукой годные ссылки, то буду благодарен.


S>Во-вторых, сборка в wasm упростит деплоймент, но вряд ли улучшит быстродействие. Потому что узким местом LSP всё равно является JSON-RPC.

Ну, я очень мало знаю о том, как устроен VSCode, и пока не копал. Слышал, что он весь из себя на JS сделанный, и плагины тоже как-то так делаются. Про web assembly я тоже очень мало знаю, но, теоретически, это вроде как единственный путь собирать плюсовый код, чтобы он работал на жиэсе.


S>Встроить раскраску синтаксиса во встроенный редактор можно только через LSP либо TextMate2. Если вы захотите делать inproc-раскраску, вам придётся напилить свой custom editor.

LSP — понятно, а TextMate/2 — что за зверь? Какие с ним проблемы? (Да, я бегло погуглил, но ничего не понял )


M>>Не костыля, а плагина
S> А какой смысл тогда называть "это" токенизатором, если у него внутри полноценный парсер?

Так не полноценный же. Сам по себе, без надстроек — он вполне себе только токенизатор.

У меня ещё есть разделение на TokenizerBuilder и Tokenizer. Сейчас TokenizerBuilder умеет создавать Tokenizer, но, теоретически, TokenizerBuilder будет уметь сериализовать Tokenizer в плюсовый код, из которого можно создать Tokenizer. А этот Tokenizer можно будет запихать без билдера в STM32, чтобы он там что-то простецкое разбирал. Но я пока эту ветку не прорабатывал.


M>>Вы хотели сказать, наверное, lex+yacc/flex+bison?
S>Наверное. Но глядя на примеры "PEG" для плюсов (https://github.com/taocpp/PEGTL/blob/main/src/example/pegtl/calculator.cpp) я вижу, что проблема не столько в конкретном выбранном виде парсеров, сколько в твёрдом убеждении их авторов в неизбежности страданий. Типа, "нельзя просто написать грамматику с действиями и разбирать ей тексты!". Надо получить обязательную порцию унижений в виде пачки бойлерплейта. В итоге, калькулятор с 18 операциями превращается в 360 строк кода . При этом, собственно, от грамматики в исходнике ничего не остаётся — всё размазано по вспомогательным структурам и рукопашным методам match.

Глянул, что-то такое себе


S>Вот этот вариант выглядит получше, но всё делает в рантайме. Из этого мы сразу выводим что
S>а) косяки в грамматике тоже обнаружатся в рантайме, а в компайл-тайме нам ничего не скажут. То есть "приходи, дорогой друг, завтра, когда отработают тесты найтли билда".
S>б) быстродействие, скорее всего, хуже чем у плюсовых регекспов и аналогов на Javascript.
S>В общем, беглым взглядом я ничего не нашёл. Скорее всего, можно навелосипедить приличное решение, которое умеет разбирать текст DSL, который содержит грамматику и семантические действия, и порождать код на плюсах. Вот это, собственно, и даст возможность быстро выполнять как прототипирование, так и собственно разбор текста получившимся кодом.

А вот это — интересно, надо приглядется, спасибо