В языках разметки, например, в xml и tex часто используются парные конструкции вида <div>...</div> и \begin{equation}...\end{equation}, где вместо div и equation может быть любой индентификатор, поэтому, на этапе компиляции невозможно описать все варианты. Нужно в момент исполнения при встрече, например, \begin{array} добавлять правило \begin{array}...\end{array}. Поддерживает ли сейчас такую возможность Nemerle.Peg, и если да, то как её выразить в его синтаксисе?
Здравствуйте, Рысцов Денис, Вы писали:
РД>В языках разметки, например, в xml и tex часто используются парные конструкции вида <div>...</div> и \begin{equation}...\end{equation}, где вместо div и equation может быть любой индентификатор, поэтому, на этапе компиляции невозможно описать все варианты. Нужно в момент исполнения при встрече, например, \begin{array} добавлять правило \begin{array}...\end{array}. Поддерживает ли сейчас такую возможность Nemerle.Peg, и если да, то как её выразить в его синтаксисе?
Сейчас нет.
Но никаких принципиальных препятствия я не вижу так что в будущем наверняка появится.
Сейчас план развития примерно такой:
1)Довести до ума востановление после ошибок. (Выносит мозг. Особенно в сочитании со следующим пунктом.)
2)Сделать возможность изменять граматику во время разбора. На этой же стадии неизбежно появятся приоритеты для правил.(Съест остатки мозга. Особенно пункт: Должно работать очень быстро.)
3)Сделать правила высшего порядка. (Это должно быть довольно просто.)
те в место того чтобы каждый раз писать
ruleList : list[Rule] = rule (","s rule)*;
можно будет написать
list[T] rule delim : list[T] = rule (delim rule)*;
и дальше можно будет писать
ruleList : list[Rule] = list rule (","s);
Дальше можно будет подумать о чемто еще.
Предлагать можно уже сейчас.
Желательно с описанием синтаксиса.
ЗЫ Парсер находится в активной стадии разработки и как следствие возможны ломающие изменения без предупреждения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
РД>>Нужно в момент исполнения при встрече, например, \begin{array} добавлять правило \begin{array}...\end{array}. Поддерживает ли сейчас такую возможность Nemerle.Peg, и если да, то как её выразить в его синтаксисе? WH>Сейчас нет. WH>... WH>Предлагать можно уже сейчас. WH>Желательно с описанием синтаксиса.
Тот вариант, с которого я начал сообщение, можно было бы встроить следующим способом:
...
expression : SomeAst = ...
beginEnd : SomeAst = let tag = ['a'..'z','A'..'Z']+ in"\begin{" tag "}" expression "\end{" tag "}"
...
Где вместо ['a'..'z','A'..'Z']+ могла бы быть любая последовательность правил.
Здравствуйте, Рысцов Денис, Вы писали:
РД>В языках разметки, например, в xml и tex часто используются парные конструкции вида <div>...</div> и \begin{equation}...\end{equation}, где вместо div и equation может быть любой индентификатор, поэтому, на этапе компиляции невозможно описать все варианты. Нужно в момент исполнения при встрече, например, \begin{array} добавлять правило \begin{array}...\end{array}. Поддерживает ли сейчас такую возможность Nemerle.Peg, и если да, то как её выразить в его синтаксисе?
Я не очень понимаю зачем тут вводить какие-то новые правила. В грамматике нужно указывать "идентификатор", а соответствие парных элементов проверять уже в обработчике правила.
Собственно я сам лично сделал грамматику разбирающую расширенный вариант ХМЛ-я на текущей версии PegGrammar (точнее на совсем древней, но только что синхронизировал ее с современной версией).
Проверки парности тегов осуществляются в обработчиков tagFull:
//tagFull : Tag = tagOpen content* tagClose;
tagFull(tagOpen : TagOpen, content : List[XmlAst], tagClose: TagClose) : XmlAst
{
def open = tagOpen;
def closeIdent = tagClose.ident;
unless (closeIdent is Splicable.Value("") || open.ident.Equals(tagClose.ident))
{
Message.Error(ToLocation(open.ident), "Tag was not closed.");
Message.FatalError(ToLocation(tagClose.ident), $"Expecting end tag </$(open.ident)> or </>.");
}
def cont = open.attrs.Map(x => x) + content.Map(x => x);
Tag(tagOpen.StartPos, tagClose.EndPos, open.ident, cont)
}
И даже хорошо, что проверка делается именно, тут так как это позволяет выдать понятное диагностическое сообщение и указать на открывающий тег, а не просто выдать нечто "Ожидается tagClose".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я не очень понимаю зачем тут вводить какие-то новые правила. В грамматике нужно указывать "идентификатор", а соответствие парных элементов проверять уже в обработчике правила.
В случае валидного xml действительно не составляет труда так делать, но вот html (например, <div><br></div>) так уже не обработать.
Здравствуйте, Рысцов Денис, Вы писали:
РД>В случае валидного xml действительно не составляет труда так делать, но вот html (например, <div><br></div>) так уже не обработать.
В приципе можно. Придется, правда, раскидывать теги вручную, преобразовывая AST.
Здравствуйте, Рысцов Денис, Вы писали:
РД>В случае валидного xml действительно не составляет труда так делать, но вот html (например, <div><br></div>) так уже не обработать.
Дык ХТМЛ вообще язык слабо структурированный. В нем теги могут вовсе не закрываться. Тут разбор придется делать более сложный. На вряд ли тут помогут парсеры контекстно-свободных грамматик.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>3)Сделать правила высшего порядка. (Это должно быть довольно просто.) WH>те в место того чтобы каждый раз писать WH>ruleList : list[Rule] = rule (","s rule)*; WH>можно будет написать WH>list[T] rule delim : list[T] = rule (delim rule)*; WH>и дальше можно будет писать WH>ruleList : list[Rule] = list rule (","s);
Ты часом не пытаешся Пролог второй раз изобрести?
ЗЫ
Ты куда пропал в Скайпе?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
