ссылок на литературу там нет, потому что Игорь Русских не смотрел никуда когда делал Colorer. Короче, история такая, давным давно, в прошло столетии в редакторе Farа не было подсветки синтаксиса. А очень надо было. Потому Евгений Рошаль просто предоставил соответствующее API писателям расширений, и дальше уже как-то само пошло. Игорь Русских написал свою библиотеку regexp-ов (не особо заморачиваясь детерминированием КА, и работавшими с откатами). К счастью я ему не успел рассказать, что на регулярках не отследить баланс скобок, как он сделал баланс скобок на паре регулярных выражений (начало и конец блока) с переключением в другую схему.
Такой подход, на практике, не сильно отличается от переключения стейта в том же flex-е, но со стеком состояний и вложенными схемами, позволило покрыть большой (очень большой) класс языков.
Да, там регулярки с костылями, но достаточно элегантными костылями.

элегантные костыли :)

Ну количество используемых скобок всё-таки конечно, при должно старании наверно можно забить на наиболее часто используемую глубину. Так что да, переключение элегантно. 😊

Файл документации по формату HRC Colorer показывает, что автор плагина увлекся оверинжинирингом: http://colorer.sourceforge.net/hrc-ref/index.html

Добавление стека к регулярным выражениям это не такой уж «костыль», как может показаться. Обратите внимание, что о каком-то ограничении глубины стека речь не идет.  В идеальном варианте мощность полученного решения на HRC должна соответствовать недетерминированному автомату с магазинной памятью — который справляется с  разбором всего класса контекстно-свободных языков.

Хорошей альтернативой всем этим XML, регионам и схемам из HRC был бы, например, формализм PEG, который по сути и основан на нотации рег. выражений и рекурсии.

В целом, с точки зрения теории синтаксического разбора здесь, разумеется, никаких откровений нет. Более того, иной раз удобно подсветку синтаксиса осуществлять сразу на основе работы штатного парсера рассматриваемого языка. Действительно, зачем лишний раз производить одни и те же действия по разбору, если мы в IDE и так совершаем проверку синтаксиса, автоформатирование текста и т.д. См. выше упоминание протокола LSP.

Повторюсь, откровений нет, но за одним важным исключением — мы бы не хотели, чтобы при каждом нажатии клавиши пользователем в редакторе парсер заново разбирал бы весь исходный текст. Поэтому необходимы инкрементальные подходы. Именно их реализация и вызывает интерес — любопытно, к примеру, как это сделано в том же FAR.

А разве основная причина инкременталки не то, что текст в процессе редактирования проходит фазы когда парсер компилятора выдаёт ошибку?

Кроме того, разве для некоторых языков цели  построения AST и устойчивой к редактированию расцветки не могут быть противоречащими друг другу?

То есть, вы убираете пару символов и AST кардинально перестраивается.

Забавно рантайм компилятора Grain (функциональный ЯП написанный на Ocaml) будет написан на AssemblyScript и для начала автор решил перевести MurmurHash3:
https://github.com/grain-lang/grain/pull/98

Понятно, спасибо!

> потому что Игорь Русских не смотрел никуда когда делал Colorer.

Мне, кстати, сперва показалось, что решение чуть ли не "содрано" с vim-а. ;)

Но присмотревшись (и увидев некоторые существенные отличия в деталях), я понял, что, по-видимому (так же, как и Игорь Русских) авторы syntax highlighters, когда решают эту проблему, просто интуитивно (т.к. теории, как и я они не находят — может, её всё-таки, и нет?) реализуют примерно то же самое. А потом "допиливают" по ходу реализации подсветки для конкретных языков, когда становится понятно, что у существующей реализации не хватает "мощности", или становится очевидным, что что-то можно было бы сделать удобнее.

> он сделал баланс скобок на паре регулярных выражений (начало и конец блока) с переключением в другую схему.

И это уже — совсем не регулярки, а что-то другое (и куда мощнее, чем они)!

> но со стеком состояний и вложенными схемами, позволило покрыть большой (очень большой) класс языков.

А вот это, собственно, и есть тот подход, к которому (по мере разработки, видимо) и приходят авторы highligthers, способных покрыть очень большой класс языков. ;)

Вот об этом я и писал / спрашивал всё это время!
"Регулярки" там только основа, как lexer-ы в компиляторе, и говорить, что это "тупо регулярки" — неправильно, ровно также, как и утверждать,что "обычные" компиляторы могут разбирать только регулярные языки (потому что "там же регулярки" (в lexer)). ;)

> который справляется с  разбором всего класса контекстно-свободных языков.

vim, например, своими "костылями" разбирает не только контекстно-свободные, но и те контекстно-зависимые конструкции, которые встречаются в реальных ЯП. ;)

> В целом, с точки зрения теории синтаксического разбора здесь, разумеется, никаких откровений нет.

Вам виднее. Но что там есть (и в аналогах) — это, фактически, удобный для описания highlighting DSL, который, к тому же, позволяет обойтись без lexer hacks (на каком-то универсальном ЯП), когда язык вдруг оказывается формально контекстно-зависимым.

> Поэтому необходимы инкрементальные подходы.

И это тоже. Цитируя vim manual: "Compilers have it easy.  They start at the beginning of a file and parse it straight through. Vim does not have it so easy. It must start in the middle, where the editing is being done."
Особенно это проявляется на файлах размером в сотни мегабайт, да. ;)

Коллеги, а почему в скриптовых языках так любят динамическую типизацию? Считается, что это проще для пользователя? Но ведь всё равно за типами приходится следить, а узнать об ошибке типов можно только запустив программу и дождавшись вызова проблемной функции. Да и виртуальная машина медленнее, если контроль типов ложится на неё.

Ну наверное потому что предварительная компиляция не нужна?

Практически нулевое время от редактирования кода до запуска

Так проще для реализации языка. Не нужно писать тапчекер - уже меньше работы. И да, многие пользователи предпочитают динамическую типизацию.
ВМ для динамических языков тоже проще (или не сложнее), если не заморачиваться. В какой-то степени проверять типы приходится и ВМ для компилируемых языков.

Это какие динамические языки сейчас не делают предварительной компиляции? 😃

AWK - это не "сейчас". 😉

Ну это не тоже самое по времени, что компиляция любого статического языка

Поэтому практически)

Если мы возьмём "любые" (произвольные, случайные) языки, то результаты будут в обе стороны.

Зато немало циклов отладки после запуска, и каждый из них отнимет немало, пока снова загрузится среда, модули, библиотеки.

Это само собой