Входная грамматика

[TonitaN]

Для совместности с тестирующей системой @mathhyyn выкладываю сюда предложение по грамматике

<regex> ::= <n-alt-regex> <alt> <regex> | <conc-regex> | пусто
<n-alt-regex> ::=  <conc-regex> | пусто
<conc-regex> ::= <simple-regex> | <simple-regex><conc-regex>
<simple-regex> ::= <lbr><regex><rbr><unary>? | буква <unary>?
<alt> ::= '|'
<lbr> ::= '('
<rbr> ::= ')'
<unary> ::= '*' \\ и по желанию '+'

В кавычках - символы языка, чтобы не путать их с символами метаязыка; во входных данных кавычки для обозначения скобок, альтернатив и итераций использовать не надо. Регулярки, конкатенирующие или итерирующие пустые строки, объявляем патологическими. Эта грамматика имеет тот недостаток, что пропускает их, если они взяты в скобки. Поэтому дополнительно если в регулярке встретилась вот такая подстрока '('('|')*')' (открывающие и закрывающие скобки, которые не содержат ничего, кроме, может быть, альтернатив), то такую регулярку объявляем ошибочной.

[TonitaN]

Это нужно будет не забыть обновить с учётом нововведений.

[TonitaN]

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

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

Будем думать.