Здравствуйте, Marty, Вы писали:
M>Я пока не очень разобрался, как всё это работает в конкретных инструментах, но наверное на каждое правило должно быть навешено какое-то действие, типа, добавить элемент в AST. Можно считать, что код по навешиванию действий в PEG варианте не входит в парсер, а во втором варианте считать наоборот
Ну, вообще на эту тему чуть больше мнений, чем есть реализаций PEG. Но более-менее традиционным всё же считается подход, в котором semantic actions вписаны прямо в грамматику.
Можно и по-другому, но тогда начинаются всякие мелкие неприятности при написании, да и читаемость страдает.

M>То есть, inproc-плагины — это говно, а по пайпу туда-сюда гонять джейсон — это офигенно?
Конечно. Основная причина — криворукий плагин не роняет студию, а просто отпадает, ни на что не влияя.
А то, что там гигабайты под капотом летают — ну и хрен с ними, пока это не мешает пользоваться студией. Многочисленные преимущества вот так вот взяли да и перевесили недостатки.

M>Не очень понял.
А что тут не понять? Бенчмаркать "чистый токенизатор", который отдаёт результат в dev/null, не имеет никакого смысла. Это всё равно, что мерить скорость какого-нибудь "i++".
Интересна скорость прикладной задачи с использованием различных решений.
M>Мой токенизатор может порождать стилизированный HTML, я уже приводил этот пример. И я могу без проблем какому-то хосту отдавать информацию, что и с какой позиции надо красить каким стилем.
Всё упирается в то, каким способом это отдаётся этому хосту. Понимаете, лексический анализ при правильной реализации — штука феерически дешёвая. Ну, то есть понятно, что ваш код теоретически можно разогнать ещё в три-пять раз, но даже уже и так он работает настолько эффективно, что становятся заметны вызовы getNext. Любое использование результата вызова getNext будет ещё заметнее.
M>Это интересно, но не на столько, чтобы я кинулся сейчас сразу искать информацию на эту тему. Если есть под рукой годные ссылки, то буду благодарен.
Годные ссылки лежат прямо на сайте VS Code — с пошаговыми тьюториалами и примерами. На данном этапе важно понять принцип: собственно JSON-RPC был там придуман ровно для того, чтобы LSP можно было реализовать на чём угодно, хоть даже и на плюсах. Поэтому, к примеру, сервер для Rust написан на Rust, а сервер для Java — на Java.

M>Ну, я очень мало знаю о том, как устроен VSCode, и пока не копал. Слышал, что он весь из себя на JS сделанный, и плагины тоже как-то так делаются. Про web assembly я тоже очень мало знаю, но, теоретически, это вроде как единственный путь собирать плюсовый код, чтобы он работал на жиэсе.
VS Code совершенно всё равно, на чём работает ваш код. Да, работа на JS упрощает деплоймент, потому что не нужно думать о том, как запустить ваш код на конкретной платформе. А в остальном стандартный способ — стартовать процесс на том, на чём он написан, и работать с ним через локальные веб-вызовы.
И даже это не единственный способ — поскольку VS Code умеет работать в веб (zero-deployment), ваш LSP сервер вообще может торчать в интернете, и VS Code будет с ним работать на лету через честное сетевое соединение.
Но я эту возможность пока что мало изучал, по ряду административных причин.

M>LSP — понятно, а TextMate/2 — что за зверь? Какие с ним проблемы? (Да, я бегло погуглил, но ничего не понял )
Это и есть раскраска на регекспах. Она полностью декларативна в том смысле, что никакого кода вы не пишете. Пишете более-менее развесистый набор правил, и отдаёте их примерно в любой редактор, который поддерживает этот стандарт.

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


M>У меня ещё есть разделение на TokenizerBuilder и Tokenizer. Сейчас TokenizerBuilder умеет создавать Tokenizer, но, теоретически, TokenizerBuilder будет уметь сериализовать Tokenizer в плюсовый код, из которого можно создать Tokenizer. А этот Tokenizer можно будет запихать без билдера в STM32, чтобы он там что-то простецкое разбирал. Но я пока эту ветку не прорабатывал.
Ну, в целом это и есть самый конструктивный подход. Потому что если делать "только конфигурацию в рантайме", то вы пропустите оптимизации. Будет примерно то же самое по производительности, что и регекспы на плюсах (я же правильно понял, что там они всё ещё интерпретируются?). А если делать рукопашное написание токенизатора, то код становится громоздким и плохо поддерживаемым.
Так что да — берём код грамматики на удобном DSL, по нему строим код на целевом языке и алга. Ну, там дальше возможны варианты — не обязательно же сначала порождать код C++, чтобы потом его какой-нибудь Clang или ICC превращал в LLVM IR. Можно и сразу LLVM IR порождать, минуя лишний этап.