Кстати, про парсеры тут сказано было много, а что насчёт

лексеров?
Есть какие-то общепринятые подходы к созданию лексеров, может даже языки описания лексем и алгоритмы разбора текста на лексемы?

https://www.spoofax.dev/references/syntax/layout-sensitivity/

У вас тут половина ответов - «как в Spoofax»…

Ага. Я знаю. 😂

Ну и ответы эти, опять-таки, "слабые", IMNSHO. Вот это https://t.me/CompilerDev/103176 сводится к "мы придумали специальные конструкции (black boxes) для конкретных задач (не основанные на базовых возможностях формализма), внедрили их в формализм, и делаем вид, что так и надо", нет? ;)

Это Вы из статьи по сноске такой вывод сделали? А в "мы придумали специальные конструкции (black boxes) для конкретных задач (не основанные на базовых возможностях формализма)" Вы какой конкретно формализм имеете в виду?

> Это Вы из статьи по сноске такой вывод сделали? Вы имеете в виду Sebastian Erdweg, Tillmann Rendel, Christian Kästner, and Klaus Ostermann. "Layout-sensitive generalized parsing."? Нет, её я не читал, вывод сделал только по описанию в приведённой ссылке. Так что, я ошибся (и это в самом деле реализовано на основании базовых возможностей)? > какой конкретно формализм имеете в виду? SGLR.

> Так что, я ошибся (и это в самом деле реализовано на основании базовых возможностей)? >> какой конкретно формализм имеете в виду? > SGLR. Ну, там всё построено поверх SGLR, но я не знаю, что Вы считаете "базовыми возможностями" или "базовым формализмом" SGLR. 🤷‍♀️

(Пролистал статью) Нда. "After parsing, we disambiguate the resulting parse forest by traversing it. Whenever we encounter the application of a layout-constrained production, we check that the layout constraint is satisfied." Ну и так далее, суть не меняется. И это всё, разумеется, не выражается через примитивы SGLR ([reject] productions и follow restrictions), да? Понимаете, это какой-то "интересный" подход (например, аналогичный тому, как "декларативные" perl regexes (PCRE) распознают все CFG и немало CDG... тонкость в том, что это запись программы для "императивной машины", которая старается быть очень похожей внешне на декларативное выражение). ;) Вот из статьи: For example, the standard Python lexer and parser are handwritten C programs. While parsing, the lexer checks for changes of the indentation level in the input, and marks them with special indent and dedent tokens. The parser then consumes these tokens to process layout-sensitive program structures. This implementation is non-declarative. А если я добавлю в bison/flex возможность "декларировать" что-то вроде: %use identation_tokens {INDENT DEDENT} ну и далее буду использовать эти токены в грамматике, то implementation сразу станет declarative, проблема решена? По-моему, нет — это всего лишь blessed hack. И авторы, по сути, сделали то же самое. В общем, если убрать это расширение из Spoofax, то layout constrains записать там станет невозможно, я правильно понял? > но я не знаю, что Вы считаете "базовыми возможностями" или "базовым формализмом" SGLR. 🤷‍♀️ То, что описано (возможно, в старых) статьях о SGLR.

> это запись программы для "императивной машины", которая старается быть очень похожей внешне на декларативное выражение Круто, если у Вас есть истинно декларативная машина, а мне приходится работать на императивной (Intel Core i7 based). 😂

Вы что сказать-то хотели? У настоящих, декларативных regular expression есть куча полезных теоретических свойств (closure properties, соотношения с грамматиками других типов в иерархии Хомского, algebraic laws, эквивалентность их NFA/DFA — а это известные сложности recognition/matching, эквивалентность [языков для] данных выражений, возможность реализации разными алгоритмами и декларативной оптимизации, опять же; и т.д. и т.п.). А у внешне похожих на них языков для императивных машин (PCRE)... гарантированных свойств вроде вышеупомянутых просто нет (и от перемены мест "слагаемых" иногда меняется "сумма" (leftmost first); и то, что они распознают, фактически определяется конкретной реализацией; и время работы, и используемая память — "как повезёт" (несложно добиться 2ⁿ, если захотеть); ну и так далее). IMNSHO, это очень существенная разница.

Если поднять глаза от SGLR к SDF3 — а layout constraints относятся именно к SDF3 — то у него тоже имеются приятные свойства — в первую очередь композициональность — вне зависимости от того, как он реализован "внутри".