Грамматика описана на нескольких страницах. Три основных:
http://goldparser.org/doc/grammars/define-rules.htm
  описывает "правила"
http://goldparser.org/doc/grammars/define-terminals.htm
  описывает "терминалы" (регэкспы)
http://goldparser.org/doc/grammars/define-sets.htm
  описывает "символы" ("set notation"). Тут есть операция "-".

правило := альтернативное подправило, { " | " , альтернативное подправило } ;
альтернативное подправило := { пустое множество | ( ( терминал | нетерминал ) , { терминал | нетерминал } ) }

терминал := выражение , { "|" , выражение } ;
выражение := элемент выражения, { элемент выражения } ;
элемент выражения := ( имя множества | регэксп |  строка ) , [ "*" | "+" | "?" ] ;

Здесь не очень удачно:
1) то, что страницы не содержат достаточно гиперссылок на смежные страницы. В частности нет ссылки на оглавление. Это неудобно, потому что пользователь пришедший на страницу из поисковика не сразу поймет как перейти на начало описания (для этого надо обрезать URL- http://goldparser.org/doc/grammars/. В целом это стандартный приём, но старый, не все о нём знают).
Так случилось из-за того, что были использованы "фреймы HTML", не надо было их использовать.
2) при описании регэкспов нет логической связки между словами "set literal" и "regular expression", читатель должен строить догадки (и терять время на их проверку). То же самое относится к слову "defined sets" - его нет на картинках, однако его вводят/используют в "поясняющем" тексте из ниоткуда.
Описание "defined set" использует отсылку к другому генератору (Lex/Yacc), что не подойдёт в случае самостоятельного русского туториала. В русском туториале надо будет определять термины (вроде "символьное имя регулярного выражения"), и соответствующий синтаксис надо тоже будет определять формально. Т.е. регулярное выражение может включать в себя другое регулярное выражение, если имя второго выражения заключено в фигурные скобки. Вообще-то таким образом можно определить КС-грамматику. Как парсер борется с этим, когда нет надёжного способа определить - является ли грамматика регулярным выражением, или КС-крамматикой, я не знаю.
3) характерным отличием этой грамматики является использование угловых скобок для группировки имён правил (вместо запятых из стандарта ISO EBNF). Два символа - это ещё больше чем один (запятая) или ни одного (как пробелы в ABNF из RFC).
Зато, это единственная грамматика, где пустое множество может быть записано в явном виде (запись пустого множества в явном виде на мой взгляд может повысить понимаемость грамматики в некоторых случаях).
4) неясно, почему на картинке при описании правил нарисовано "=", а в тексте используется "::=". То ли это устаревшая картинка, то-ли ещё что. Вводит читателя в неуверенность в правильном понимании прочитанного.
5) пример с определением списка на странице описания правил провокативен, использует левую рекурсию там, где это совершенно не нужно. Таким образом он создаёт порочную практику у пользователей этого руководства, что будет мешать в дальнейшем пользователям перейти с этого инструмента на другие. Это подлая отрыжка капиталистических принципов.
Но вообще сама идея привести примеры именно так, и подбор примеров мне кажутся удачными (для того, чтобы тоже так делать при описании русского движка).
6) Странное использование фигурных скобок. Они используются не как символ повторения. Для указания на повторения используется символ "*". В то же время фигурные скобки не используются каждый раз, когда надо сослаться на что-нибудь:

Код:
Identifier = {Letter}{Alphanumeric}*
<List> ::= <List> ',' <List Item>
        |  <List Item>
<List Item> ::= Identifier

Здесь не ясно, почему в последней строке Identifier не взят в фигурные скобки. Это ведь нетерминал. Возможно, скобки используются только для вставки регулярных выражений только в правила, а одни регулярные выражения в другие вставлять нельзя, - это бы всё объясняло. И ещё, при описании регулярны выражений используется "=", а при использовании правил - "::=". Но почему об этом надо догадываться?
7) не полностью расписан пример с "висящим else". Что если я хочу, чтобы он относится не к последнему if-у, а к первому. Как мне модифицировать грамматику для этого случая и в чем разница с вариантом, когда else относится к последнему if-у. Хорошо бы  ещё один пример про схожую, но другую конструкцию, а то складывается впечатление, что такой конфликт может только с else произойти, а это наверное не так.
8) для обозначения диапазонов используется конструкция 
диапазон := код символа, "..", код символа ;
однако эта конструкция не нарисована в виде картинки.
9) для картинок используется .png, а пора уже давно перейти на .svg, потому что в svg можно добавлять гиперссылки. И это было бы очень удобно, если бы к описанию любого правила можно было перейти из любого места, где оно используется.

В грамматике обошлись без ескейп-последовательностей в строках, потому что есть регулярные выражения, где можно указывать коды символов. Раньше меня удивляло, зачем грамматику разбивают на регулярную и нерегулярную части. Теперь я знаю, что во всем виновата теорема Грейбах и стремление к эффективности компьютера в ущерб удобству программиста.

Разделение на "шум" и "полезные" правила.
http://goldparser.org/doc/grammars/term … ibutes.htm
я не понимаю, как так можно игнорировать задачу разделения текста на строки.
Это ведь очень важно для вывода правильной позиции ошибки в текстовом редакторе (строка такая-то, колонка такая-то). Если игнорировать переводы строк, удалять многострочные комментарии и т.п., то определять позицию прийдётся дополнительным сканом.

Код:
IgnoreMe @= { Type = Noise }
IndentDecrease @= { Source = Virtual }

Комментарии тоже нестандартные, сразу позволяют отличить эти грамматики от других:

Код:
! This is a comment
! This is also a comment
!*  Remember to always comment your code. This
   can add a great deal to readability. *!

В целом, стандартная, такая, грамматика, ничего прорывного (если сравнивать, например с W3C EBNF). А российская грамматика должна содержать инновации, не так ли?

Отредактировано Лис (2017-07-30 06:04:46)