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

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

N>>Регэкспы — давно не вкладываются в регулярные грамматики.

V>Регеспы POSIX в точности описывают регулярную грамматику.
V>Может ты имел ввиду расширенные варианты, типа https://ru.wikipedia.org/wiki/PCRE?

В первую очередь их, да. Но про POSIX ты неправ, или отстал. POSIX допускает так называемые back-references:

For example, the expression "^\(.*\)\1$" matches strings consisting of two adjacent appearances of the same substring

на регулярную грамматику ты такое не уложишь, это уже context dependent.

Там есть таракан, что по POSIX они допустимы только в basic regexps, но не extended — а расширения все делаются поверх extended (кроме vim с его спецификой), но это не отменяет их присутствия.

V>Да, в Перле регекспы расширили обратными ссылками и те перестали быть регулярными выражениями.
V>По-хорошему, термин тоже надо было изменить...

Не они первые начали. Термин, да, размылся.

N>>PEG используется каждым вторым.

V>Тю!
V>Когда-то область компиляторостроения и вообще парсинга была "необъезженной", по ней неплохо готовили специалистов, бо отрасль нуждалась.
V>С приходом XML, JSON, YAML и прочих структурированных форматов практическая надобность в большом кол-ве специалистов по парсерам иссякла.

V>Отсюда те частые наблюдения, что когда необученные программеры начинают лабать нисходящие парсеры на коленке, т.е. методом проб и ошибок, получается банальный PEG.

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

Может быть, как раз потому, что они естественно ложатся на мышление того, кто ещё не загнан правилами LL/LR на конкретные рельсы мышления и/или не понимает важности их ограничений (а, может, это одно и то же условие).

A>>>И этот тэг определяет в какой массив и какую структуру AST ты его записываешь.
N>>Есть такие языки, но в целом это неудобно.
V>В целом это сводит парсер по сложности примерно к хеш-таблице. ))

Увы, ещё нет. Посмотри на Perl
там теги типа $ — скаляр, @ — список, % — хэш, но "к хэш-таблице" его парсер несводим (не буду вдаваться в то, насколько несводим)
Ладно, на старый BASIC с его A! — целое, A$ — строка, A% — вещественное. Всё равно выражения надо парсить.

V>Первый Фортран не далеко от такого ушел (до введения типизации):
V>

V>переменные, имена которых начинаются с одной из шести букв I, J, K, L, M, N (например: IGREK5, LA, М, K2N3AB и т.д.), являются величинами целого типа, а с любой другой буквы (AL, X, DELTA и т.д.) — величинами вещественного типа.

Нет, это не "первый" Fortran. Это уже правила Fortran II.
Более того, в нём это были типы по умолчанию, и их можно было заменять явным определением типа конкретной переменной.

Fortran I имел другое правило — целое при первой букве X, все остальные буквы означают вещественные.

Но у раннего Фортрана интереснее даже не это, а фокус, как там решали проблему приоритетов.
Любое выражение обрамлялось (( )).
* и / заменялись на )*( и )/(, + и — — на ))+(( и ))-((.
Дальше логика работала только учётом скобок.
Такой себе древний самопальный аналог правил Пратта с приоритетами.