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

VD>Мы тут продумываем дизайн параметризованных правил. В двух словах параметризованные правила — это правила которые имеют нечто вроде параметра типов, но вместо типа в него подставляется другое правило. Получается что-то вроде обобщенных правил.

VD>Собственно вопрос в том насколько интуитивным являются следующие соглашения
VD>* regex — означает что правило может быть только regex-ом.
VD>* token — правило может быть token-правилом или regex-ом.
VD>* syntax — правило может быть syntax-правилом, token-правилом или regex-ом.
Я не знаю про интуитивность.

Пусть у нас есть множество типов правил X = { regex, token, syntax } и бинарное отношение R = 'правило x можно подставить в правило y'.
Тогда, мы имеем
— Рефлексивность (можно подставить x в x)
— Антисимметричность(если x можно подставить в y и y можно подставить в x, то x равен y)
— Транзитивность (если x можно подставить в y и y можно подставить в z, то x можно подставить в z)
— Линейность (x можно подставить в y или y можно подставить в x).
Выходит, что отношение отношение R = 'правило x можно подставить в правило y' является нестрогим линейным порядком. А выбранные соглашения вполне логичны.


VD>В приведенном примере тип параметра выводится из использования, т.е. при компиляции компилятор узнает тип Quote только после того как проведет анализ всех (или части) подправил. Так как параметры правил это часть публичного интерфейса, то резонно возникают сомнения относительно целесообразности его вывода.
Целесообразность состоит в том, что для определения типа правила-параметра человек вынужден проанализировать все его использования, а затем вывести корректный тип. Это машинная работа. При том, как я понимаю, процедура вывода достаточно проста — поиск правила с "наименьшим" типом, куда подставляется правило-параметр. Таким образом будет выведен "наибольший" из возможных типов для правила-параметра.

Если говорить про публичный интерфейс правила, то лучше разобрать на примере. Пусть у нас есть некоторый параметр ruleparam, который используется в правилах типа token и syntax. Для ruleparam будет выведен тип token.
Если мы избавимся от использования в правилах типа token, то тип ruleparam может быть "увеличен" до syntax, тогда весь вызывающий код останется рабочим.
Если же мы, наоборот, воспользуемся ruleparam в правилах типа regex, то тип ruleparam будет "уменьшен" до regex, вызывающий код может сломаться. Но в этом случает он сломается вне зависимости от того, указывали мы тип явно или он был выведен.
Другое дело, что может возникнуть желание указать "меньший" тип правила, чем выводимый. Полагаю, это может быть нужно для генерации более эффективного автомата, либо если "уменьшение" типа правила параметра планируется заранее (но мне сложно представить, как это возможно).
В итоге особой пользы от публичного интерфейса не видно, а удобство использование страдает, плюс бойлерплейт. Лучшим вариантом выглядит вывод по умолчанию (по вышеописанной схеме) с возможностью явно указать тип.


VD>Альтернативой выводу типа параметров может быть явная его задание при объявлении параметра.
Я полагаю, что выбрать синтаксис для обозначения типа правила-параметра нужно в любом случае. Поскольку он будет использоваться не только при возможно явном задании типа, но так же в документации и, в перспективе, в интеграции с IDE. Как я уже писал отношение подстановки правил является нестрогим линейным порядком, а для его обозначения в математике применяется символ '<='. Соответственно

token StringLiteral< Quote <= regex > = Quote StringPart* Quote

Синтаксически это выглядит некрасиво, но суть выбранных соглашений это отражает. (Я не говорю про интуитивность, так как ничего в этом не смыслю).

С другой стороны, при практическом использовании нет необходимости каждый раз пытаться как-то подчеркнуть то, что можно один раз прочитать в документации и запомнить. Так что исходный вариант
VD>

token StringLiteral<regex Quote> = Quote StringPart* Quote

представляется вполне нормальным.


VD>ЗЫ
VD>Еще, возможно, будет разумно различать аннотации для расширяемых правил (или-правила) и для обычных. Тут уже совсем не ясно как это описать синтаксически. Если есть идеи, милости просим.
Этого я не понял, надо как-то подробней обозначить проблему.