Здравствуйте, Чистяков Владислав Юрьевич, Вы писали:
Ошибки:
1)LRPEGCC.dll
2)
Состоит из необязательного предиката ('!' или '&') и идущего за ним CardinalityRule. Если предикат задан, то он делает идущее за ним подправило предикативным (эфемерным). Такое правило распознается только с целью получения ответа на вопрос, можно ли продолжать дальнейший разбор. Информация о разборе предикативного подправила теряется, а текущая позиция не изменяется.
Чего? Если уж мы говорим про предикаты то какие же они не обязательные?
3)
& – позитивный предикат. Возвращает успех, если идущее за ним правило успешно распознано, и неудачу в обратном случае.
!E – негативный предикат. Возвращает успех, если идущее за ним правило потерпело неудачу при разборе, и неудачу в случае успешного разбора.
Почему в нодном случае Е есть, а в другом нет?
4)Строковый литерал и Символьный литерал поменять местами. Ибо в примере к строковому используется символьный.
5)
Extensible – указывает, что данное правило является точкой расширения. Такие правила могут быть динамически (во время исполнения) расширены другими правилами. Данный атрибут может применяться только к правилам, содержащим невырожденный (т.е. состоящий более чем из одного вхождения) оператор приоритетного выбора (OrderedChoice), так как только он может быть расширен динамически. Точки расширения, совместно с областями видимости (Scope), можно использовать, чтобы создавать парсеры динамически-расширяемых языков (например, самого Nemerle). При этом Scope можно использовать для открытия и закрытия пространств имен, содержащих правила, расширяющие грамматику разбираемого языка, а атрибутом Extensible будут указываться те правила, которые будут динамически пополняться. Правила, помеченные атрибутом Extensible, превращаются макросом PegGrammar в массивы, которые можно пополнять динамически, и в которых правила сортируются в соответствии с их приоритетами (задаваемыми так же атрибутами).
FailureRecovery – позволяет задать «точку восстановления» после обнаруженной парсером ошибки. Данный атрибут применим к правилам, состоящим из непустого оператора приоритетного выбора (OrderedChoice). Если в грамматике не заданы точки восстановления или точки отсечения (о них см. ниже), то при обнаружении первой ошибки парсер прекращает разбор (так как все правила откатываются) и сообщает об ошибке. FailureRecovery позволяет указать, что данное правило не должно откатываться при обнаружении ошибки. Атрибут FailureRecovery задает метод-обработчик, который генерирует заглушку (AST-элемент, содержащий информацию об ошибке), а также правило, позволяющее пропустить некорректные данные во входной строке, что позволяет парсеру продолжить разбор строки, даже если она частично не соответствует грамматике разбираемого языка (содержит ошибки). Это позволяет выявлять несколько ошибок сразу.
Выделенное не верно.
6)
Если тело правила состоит из невырожденного OrderedChoice, то обработчик должен принимать ровно один параметр, тип которого должен быть совместим с типами, возвращаемыми всеми элементами OrderedChoice.
Все что требует приоритетный выбор это чтобы типы совпадали.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Чистяков Владислав Юрьевич, Вы писали:
WH>Ошибки: WH>1)LRPEGCC.dll
Писалось еще до переименования. Теперь надо править.
WH>2) WH>
WH>Состоит из необязательного предиката ('!' или '&') и идущего за ним CardinalityRule. Если предикат задан, то он делает идущее за ним подправило предикативным (эфемерным). Такое правило распознается только с целью получения ответа на вопрос, можно ли продолжать дальнейший разбор. Информация о разборе предикативного подправила теряется, а текущая позиция не изменяется.
WH>Чего? Если уж мы говорим про предикаты то какие же они не обязательные?
Того. Это же грамматика. PredicateRule остается PredicateRule даже если сам предикат не задан.
Наверно, нужно это пояснить более подробно.
WH>3) WH>
WH>& – позитивный предикат. Возвращает успех, если идущее за ним правило успешно распознано, и неудачу в обратном случае.
WH>!E – негативный предикат. Возвращает успех, если идущее за ним правило потерпело неудачу при разборе, и неудачу в случае успешного разбора.
WH>Почему в нодном случае Е есть, а в другом нет?
Кривой копипаст.
WH>4)Строковый литерал и Символьный литерал поменять местами. Ибо в примере к строковому используется символьный.
ОК
WH>5) WH>
WH>Extensible – указывает, что данное правило является точкой расширения. Такие правила могут быть динамически (во время исполнения) расширены другими правилами. Данный атрибут может применяться только к правилам, содержащим невырожденный (т.е. состоящий более чем из одного вхождения) оператор приоритетного выбора (OrderedChoice), так как только он может быть расширен динамически. Точки расширения, совместно с областями видимости (Scope), можно использовать, чтобы создавать парсеры динамически-расширяемых языков (например, самого Nemerle). При этом Scope можно использовать для открытия и закрытия пространств имен, содержащих правила, расширяющие грамматику разбираемого языка, а атрибутом Extensible будут указываться те правила, которые будут динамически пополняться. Правила, помеченные атрибутом Extensible, превращаются макросом PegGrammar в массивы, которые можно пополнять динамически, и в которых правила сортируются в соответствии с их приоритетами (задаваемыми так же атрибутами).
WH>FailureRecovery – позволяет задать «точку восстановления» после обнаруженной парсером ошибки. Данный атрибут применим к правилам, состоящим из непустого оператора приоритетного выбора (OrderedChoice). Если в грамматике не заданы точки восстановления или точки отсечения (о них см. ниже), то при обнаружении первой ошибки парсер прекращает разбор (так как все правила откатываются) и сообщает об ошибке. FailureRecovery позволяет указать, что данное правило не должно откатываться при обнаружении ошибки. Атрибут FailureRecovery задает метод-обработчик, который генерирует заглушку (AST-элемент, содержащий информацию об ошибке), а также правило, позволяющее пропустить некорректные данные во входной строке, что позволяет парсеру продолжить разбор строки, даже если она частично не соответствует грамматике разбираемого языка (содержит ошибки). Это позволяет выявлять несколько ошибок сразу.
WH>Выделенное не верно.
Что не верно то? Ты уже поясняй свои мысли.
WH>6) WH>
WH>Если тело правила состоит из невырожденного OrderedChoice, то обработчик должен принимать ровно один параметр, тип которого должен быть совместим с типами, возвращаемыми всеми элементами OrderedChoice.
WH>
WH>Все что требует приоритетный выбор это чтобы типы совпадали.
Не понял. Параметр должен быть один, это вроде факт. Что до типа, то вроде как у нас можно делать так, чтобы элементы были подтипами, а не точными типами (ковариантность).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
24>>>Первая ссылка (на грамматику C#) ведёт в никуда. A>>там парочка таких ссылок. пострадали в результате "реструктуризации" видимо VD>Именно так. Сейчас правильная ссылка: VD>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/csharp-parser/?r=9425
ага, это я уже нашёл
VD>Но видимо и она скоро изменится. VD>А какая еще ссылка не верна?
там просто на Parser.n в двух местах ссылка (второй раз в примечании где "Оказалось, что скорость парсинга на реальных грамматиках (мы использовали для тестов грамматику C# 4.0"), вот я и сказал "парочка"
Здравствуйте, VladD2, Вы писали:
VD>Того. Это же грамматика. PredicateRule остается PredicateRule даже если сам предикат не задан. VD>Наверно, нужно это пояснить более подробно.
Кручу верчу запутать хочу. Ничего не понял.
WH>>
WH>>Extensible –
WH>>FailureRecovery
WH>>Выделенное не верно. VD>Что не верно то? Ты уже поясняй свои мысли.
То что ни то ни другое не имеет никакого отношения к OrderedChoice.
Я тебе раз 50 наверное об этом говорил но ты не слушаешь.
VD>Не понял. Параметр должен быть один, это вроде факт. Что до типа, то вроде как у нас можно делать так, чтобы элементы были подтипами, а не точными типами (ковариантность).
Вот так тоже можно:
[PegGrammar(s,
grammar
{
x : int = "x"*;
s : int = (("x" x "") / ("x" x "x")) x;
})]
public class TestPraser
{
x(t : NToken) : int
{
t.EndPos — t.StartPos;
}
s(_ : NToken * int * NToken, n : int) : int
{
n
}
}
Сейчас это не работает но это бага и я ее починю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Того. Это же грамматика. PredicateRule остается PredicateRule даже если сам предикат не задан. VD>>Наверно, нужно это пояснить более подробно. WH>Кручу верчу запутать хочу. Ничего не понял.
Так яснее:
redicateRule = ('!' / '&')? CardinalityRule;
?
ОК, раз уж непонимание есть даже у тех кто в теме, надо подумать как это дело упростить.
WH>>>
WH>>>Extensible –
WH>>>FailureRecovery
WH>>>Выделенное не верно. VD>>Что не верно то? Ты уже поясняй свои мысли. WH>То что ни то ни другое не имеет никакого отношения к OrderedChoice. WH>Я тебе раз 50 наверное об этом говорил но ты не слушаешь.
Ну, про нереализованное Extensible говорить бесполезно. А вот FailureRecovery можно поговорить.
Я что-то не пойму как этот атрибут может работать не на OrderedChoice. Точнее какой в этом смысл?
Я его и задумывал исключительно для этого.
В общем, объясняй как ты себе все видишь. И по подробнее.
VD>>Не понял. Параметр должен быть один, это вроде факт. Что до типа, то вроде как у нас можно делать так, чтобы элементы были подтипами, а не точными типами (ковариантность). WH>Вот так тоже можно: WH>
WH> [PegGrammar(s,
WH> grammar
WH> {
WH> x : int = "x"*;
WH> s : int = (("x" x "") / ("x" x "x")) x;
WH> })]
WH> public class TestPraser
WH> {
WH> x(t : NToken) : int
WH> {
WH> t.EndPos — t.StartPos;
WH> }
WH> s(_ : NToken * int * NToken, n : int) : int
WH> {
WH> n
WH> }
WH> }
Можно, но причем тут это? Правило s не является не вырожденным OrderedChoice, а является Sequence-ом. Так что все правильно. Это ты ошибаешься.
WH>Сейчас это не работает но это бага и я ее починю.
Дык, поправить бы не мешало. Почему не работает?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ka3a4oK, Вы писали:
KK>Мне кажется, или это правда, что синтаксис описания грамматики в виде атрибута класса трудно совместим с модульностью?
Кажется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
VD>>Именно так. Сейчас правильная ссылка: VD>>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/csharp-parser/?r=9425 VD>>Но видимо и она скоро изменится.
KV>Если явно указывается ревизия, то по идее такая ссылка не должна протухнуть после переноса этого каталога в другое место в другой ревизии.
Во-первых, не работает: здесь
Во-вторых, это тоже не выход из ситуации.
Тут скорее имеет смысл задействовать редикрект вроде того что у нас для рекламмных банеров используется. За одно статистику можно посчитать .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ka3a4oK, Вы писали:
KK>Мне кажется, или это правда, что синтаксис описания грамматики в виде атрибута класса трудно совместим с модульностью?
Что подразумевается под модульностью в данном контексте? Если вы хотите хранить грамматику отдельно от парсера, то можно поинтересоваться зачем? В случае если вам надо делать парсинг, загружая грамматики в runtime, то никто не мешает выделить парсеры в отдельные сборки, реализовать в них какой-то интерфейс и получать через фабрику, тем самым обеспечивая динамику и слабую связность между клиентским кодом и парсером.
Здравствуйте, Ka3a4oK, Вы писали:
KK>Мне кажется, или это правда, что синтаксис описания грамматики в виде атрибута класса трудно совместим с модульностью?
Если имеется ввиду разбиение грамматики на куски, действительно не очень, только пресловутыми точками расширений.
Только надо ли оно? Даже грамматика C# вполне обозрима и читабельна. Класс сделан partial и методы обработки грамматики разбиты по файлам.
тогда работает.
VD>Во-вторых, это тоже не выход из ситуации. VD>Тут скорее имеет смысл задействовать редикрект вроде того что у нас для рекламмных банеров используется. За одно статистику можно посчитать .
Можно использовать уже существующий сокращатель ссылок. Тот же goo.gl дает возможность просмотра истории кликов и статистики: количество кликов, рефереры, география кликающих и т.п. Сделать свой сокращатель или редиректор в принципе несложно, заодно научить его следить за живостью ссылок и сообщать в случае чего их авторам.
Здравствуйте, Visor2004, Вы писали:
V>Что подразумевается под модульностью в данном контексте?
Возможность разбить грамматику на части собирать реальную грамматику из частей. Например, выделить разбор чисел в отдельную грамматику и подключать ее в другие (более большие грамматики) когда нужно.
Организация в виде атрибута этому никак не препятствует. Но чтобы данная функциональность появилась нужно ее реализовать. Примерный принцип описывал Вольфхаунд еще пару месяцев назад.
Однако, нам сейчас важнее динамическая расширяемость. Так что я бы не распылялся. Еще важной фичей являются точки отсечения. Без них реализовать качественные сообщения об ошибках будет не просто.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Только надо ли оно? Даже грамматика C# вполне обозрима и читабельна. Класс сделан partial и методы обработки грамматики разбиты по файлам.
Модульность предназначена не только для борьбы с размерами кода, но и для борьбы с копипастом. Например, почти все сишныеп языки имеют одинаковую грамматику для числе, комментариев и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Visor2004, Вы писали:
V>>Что подразумевается под модульностью в данном контексте? VD>Возможность разбить грамматику на части собирать реальную грамматику из частей. Например, выделить разбор чисел в отдельную грамматику и подключать ее в другие (более большие грамматики) когда нужно. VD>Организация в виде атрибута этому никак не препятствует. Но чтобы данная функциональность появилась нужно ее реализовать. Примерный принцип описывал Вольфхаунд еще пару месяцев назад. VD>Однако, нам сейчас важнее динамическая расширяемость. Так что я бы не распылялся. Еще важной фичей являются точки отсечения. Без них реализовать качественные сообщения об ошибках будет не просто.
Забавная фича, но где она реально нужна? мне в голову приходит только поддержка нескольких диалектов одного языка. Широко распространен в этом смысле только SQL, как часто люди пишут парсеры SQL
Здравствуйте, Чистяков Владислав Юрьевич, Вы писали:
В списке главных достоинств вот это не одно и то же?
Благодаря тому, что PegGrammar предоставляет концепцию областей видимости (Scopes), он позволяет разбирать ряд контекстно-зависимых грамматик вроде грамматик языков C, C++ или Nemerle.
Scope позволяет разбирать некоторые контекстно-зависимые грамматики, например С/C++.
Здравствуйте, Visor2004, Вы писали:
V>Забавная фича, но где она реально нужна? мне в голову приходит только поддержка нескольких диалектов одного языка. Широко распространен в этом смысле только SQL, как часто люди пишут парсеры SQL
Здравствуйте, Visor2004, Вы писали:
V>Забавная фича, но где она реально нужна? мне в голову приходит только поддержка нескольких диалектов одного языка. Широко распространен в этом смысле только SQL, как часто люди пишут парсеры SQL
Для парсинга того же Nemerle нужна.
Плюс имея динамическое расширение модульность будет автоматом. А там уже и статическое расширение приделать будет не сложно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Vlad2, Вы писали Статья: Макрос PegGrammar.
"Буду краток" (ц)
1. Статья напоминает расширенную документацию к PEGGrammar. Это её прямое назначение или это должно было быть введением для новичков?
2. Неплохо бы расписать роль PEGGrammar в цепочке компиляторных модулей — что даём на вход, что происходит внутри, что имеем на выходе и как этот выход использовать.
3. Хотя бы небольшой пример грамматики (раз уж так подробно расписываются возможности макроса), но желательно с охватом всех этих возможностей — чтобы наглядно было видно, что и зачем применять. Я, например, не уловил назначение "точки восстановления" (которую можно вставлять практически после любого правила) и "точки отсечения" (которые, похоже, нужны только в IntelliSence?).
4. Попытка использовать PEGGrammar из C# сразу провалилась — нет атрибута PegGrammarAttribute! Получается, это только Немерловое решение?
Здравствуйте, matumba, Вы писали:
M>2. Неплохо бы расписать роль PEGGrammar в цепочке компиляторных модулей — что даём на вход, что происходит внутри, что имеем на выходе и как этот выход использовать.
На вход подаем строку, внутри происходит разбор по правилам, на выходе то, что сгенерят правила. Не думаю, что это обязательно разжевывать в статье, но можно и разжевать.
M>3. Хотя бы небольшой пример грамматики (раз уж так подробно расписываются возможности макроса), но желательно с охватом всех этих возможностей — чтобы наглядно было видно, что и зачем применять. Я, например, не уловил назначение "точки восстановления" (которую можно вставлять практически после любого правила) и "точки отсечения" (которые, похоже, нужны только в IntelliSence?).
Примеры уже были, тот же калькулятор.
M>4. Попытка использовать PEGGrammar из C# сразу провалилась — нет атрибута PegGrammarAttribute! Получается, это только Немерловое решение?
Естественно. Это макрос который генерит код парсера. Генерить произвольный код во время компиляции в C# не умеет.
Зато полученный парсер вполне юзабелен откуда угодно в .net.
Здравствуйте, matumba, Вы писали:
M>1. Статья напоминает расширенную документацию к PEGGrammar. Это её прямое назначение или это должно было быть введением для новичков?
Это и есть документация.
M>2. Неплохо бы расписать роль PEGGrammar в цепочке компиляторных модулей — что даём на вход, что происходит внутри, что имеем на выходе и как этот выход использовать.
На входе грамматика и обработчики. На выходе то что эти обработчики сформируют.
M>3. Хотя бы небольшой пример грамматики (раз уж так подробно расписываются возможности макроса), но желательно с охватом всех этих возможностей — чтобы наглядно было видно, что и зачем применять. Я, например, не уловил назначение "точки восстановления" (которую можно вставлять практически после любого правила) и "точки отсечения" (которые, похоже, нужны только в IntelliSence?).
Для этого нужно отдельную статью писать. Примеров же масса. Загляни в сниппетыю
M>4. Попытка использовать PEGGrammar из C# сразу провалилась — нет атрибута PegGrammarAttribute! Получается, это только Немерловое решение?
Естественно. Это же макрос. Причем синтаксический. Шарпу такое даже не снилось.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, matumba, Вы писали:
M>3. Хотя бы небольшой пример грамматики (раз уж так подробно расписываются возможности макроса), но желательно с охватом всех этих возможностей — чтобы наглядно было видно, что и зачем применять. Я, например, не уловил назначение "точки восстановления" (которую можно вставлять практически после любого правила) и "точки отсечения" (которые, похоже, нужны только в IntelliSence?).
Посмотри грамматику препроцессора C# и как он работает с полученным AST (интерпретирует код).
Препроцессорный парсер: PreParser.n
AST: PreParser_AST.n
Препроцессор: Preprocessor.n
Здравствуйте, VladD2, Вы писали:
VD>Это слишком сложно для начала. Грамматики калькулятора и джейсона тут будут более кстати.
Грамматику джейсона стоит отрефакторить. Я вижу как мои первые потуги в деле использования PEG-а уже пошли копипастой: правила вида UPPERCASE = "закорючка" это не круто.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>Посмотри грамматику препроцессора C# и как он работает с полученным AST (интерпретирует код).
VD>Это слишком сложно для начала. Грамматики калькулятора и джейсона тут будут более кстати.
Парсер там примитивный — он последовательно перебирает комментарии и директивы. А вот уже о вложенности директив заботится сам препроцессор.
Здравствуйте, hardcase, Вы писали:
H>Грамматику джейсона стоит отрефакторить. Я вижу как мои первые потуги в деле использования PEG-а уже пошли копипастой: правила вида UPPERCASE = "закорючка" это не круто.
Ну, так помоги товарищу советом или физически.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Парсер там примитивный — он последовательно перебирает комментарии и директивы. А вот уже о вложенности директив заботится сам препроцессор.
Я не заочно говорил. Я посмотрел что у тебя получилось. Для новичков это явный перебор. Им нужно что-то простое и короткое (в то числе и в обработчиках).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
Z>>Только надо ли оно? Даже грамматика C# вполне обозрима и читабельна. Класс сделан partial и методы обработки грамматики разбиты по файлам.
VD>Модульность предназначена не только для борьбы с размерами кода, но и для борьбы с копипастом. Например, почти все сишныеп языки имеют одинаковую грамматику для числе, комментариев и т.п.
Не прошло и полгода
KK>Встроенные парсеры чисел(целых — в разной системе исчисления, с плавающей точкой);
Это все на фиг не нужная белиберда. В Спирете она нужна протому что он весьма убог. Грамматика для перечисленных задач пишется за две минуты.
Здравствуйте, jazzer, Вы писали:
J>Не прошло и полгода J>
KK>>Встроенные парсеры чисел(целых — в разной системе исчисления, с плавающей точкой);
J>Это все на фиг не нужная белиберда. В Спирете она нужна протому что он весьма убог. Грамматика для перечисленных задач пишется за две минуты.
Здравствуйте, jazzer, Вы писали:
J>Не прошло и полгода J>
KK>>Встроенные парсеры чисел(целых — в разной системе исчисления, с плавающей точкой);
J>Это все на фиг не нужная белиберда. В Спирете она нужна протому что он весьма убог. Грамматика для перечисленных задач пишется за две минуты.
Длы тех кто в танке. "Встроенные парсеры" — это парсеры реализованные вручную. Здесь же речь идет о возможности выделять любые правила в отдельные библиотеки. Прочти то что написано в конце того сообщения:
KK>Модульность!!! Чем дальше откладывать эту проблемму, тем, возможно, сложнее будет ее реализовать безболезненно для всех.
Вот это другой вопрос. Вольфхаунд должен был двано это реализовать. Причем должна появиться динамическая расширяемость.
Но вот что-то видимо его отвлекает. Надеюсь, что в обозримом времени он это все допишет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, catbert, Вы писали:
C>Кстати да, планируется ли поддержка парсеров сырого текста?
Вот думали для препроцессора сделать такое дело, но решили, что проще отдельный парсер сделать.
C>Типа чтобы вручную прописывать проблемные с точки зрения PEG подпарсеры.
А такие существуют?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
VD>>Что не верно то? Ты уже поясняй свои мысли. WH>То что ни то ни другое не имеет никакого отношения к OrderedChoice. WH>Я тебе раз 50 наверное об этом говорил но ты не слушаешь.
Ау... Жду развернутых объяснений. Остальные правки внес. Пока не обновляю статью чтобы не делать два раза одну и ту же работу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Для меня это стало хорошей вводной статьёй по PEG. VD>Спасибо! Рад что мой труд кому-то интересен.
"Кому-то" твой труд и так был интересен Но я прочитал начало и понял чем PEG отличается от BNF. Толково объяснена, без водички, левая рекурсия. Это важное знание, вне зависимости от языка программирования, платформы и т.д. То есть когда мне в следующий раз придётся создавать парсер на каком бы то ни было языке, с помощью какого бы то ни было инструмента, я с некоторой вероятностью загляну в твою статью. ИМХО это очень важно, когда в статьях есть не только сиюминутные конъюнктурные сведения, но и что-то более основополагающее и вечное. Так что твоя статья лично мне интересна, и спасибо тебе за неё. Вот.
Я не имел ввиду, что они должны быть вкомпилены в тело библиотеки. Конечно же отдельные парсеры. Просто я имел ввиду, что пользователю должен быть доступен некий базовый минимум парсеров — парсеры числе, например — чтобы каждый не изобретал велосипед.
Здравствуйте, Ka3a4oK, Вы писали:
KK>Я не имел ввиду, что они должны быть вкомпилены в тело библиотеки. Конечно же отдельные парсеры. Просто я имел ввиду, что пользователю должен быть доступен некий базовый минимум парсеров — парсеры числе, например — чтобы каждый не изобретал велосипед.
Вообще-то все что нужно и скопипастить не сложно. Но в общем, да, иметь возможность создавать библиотеки — это очень хорошо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
M>>2. Неплохо бы расписать роль PEGGrammar в цепочке компиляторных модулей — что даём на вход, что происходит внутри, что имеем на выходе и как этот выход использовать. VD>На входе грамматика и обработчики. На выходе то что эти обработчики сформируют.
А почему тогда предъявляется требование к возвращаемым типам? Не, отдалённо я понимаю, что генерируется AST, но т.к. ни одного реального дерева не видел, возникает вопрос: что конкретно мы имеем на выходе? Дерево с "универсальными" узлами? Или произвольными, но с заданными интерфейсами? Тут хотелось бы чуть подробнее, т.к. инфа напрямую относится к парсеру.
M>>3. Хотя бы небольшой пример грамматики (раз уж так подробно расписываются возможности макроса), но желательно с охватом всех этих возможностей — чтобы наглядно было видно, что и зачем применять. Я, например, не уловил назначение "точки восстановления" (которую можно вставлять практически после любого правила) и "точки отсечения" (которые, похоже, нужны только в IntelliSence?).
VD>Для этого нужно отдельную статью писать. Примеров же масса. Загляни в сниппетыю
Одно дело — готовые примеры (не факт, что идеальные), другое — пояснение, почему сделано именно так. Да, вторая статья практически просится!
M>>4. Попытка использовать PEGGrammar из C# сразу провалилась — нет атрибута PegGrammarAttribute! Получается, это только Немерловое решение?
VD>Естественно. Это же макрос. Причем синтаксический. Шарпу такое даже не снилось.
Да, шарп сильно отстаёт в плане макросов. Возможно, немерлистам такое замечание нафик не нужно, но я бы это упомянул в "мягких недостатках" — возможность работы только с Немерле.
Здравствуйте, matumba, Вы писали:
VD>>На входе грамматика и обработчики. На выходе то что эти обработчики сформируют.
M>А почему тогда предъявляется требование к возвращаемым типам?
Единственное требование которое к ним предъявляются, это то что они должны быть заданы явно.
M>Не, отдалённо я понимаю, что генерируется AST, но т.к. ни одного реального дерева не видел,
Так открой любой реальный парсер и погляди его. Парсер калькулятора, например, возвращает сразу результат вычисления. Парсер C#-а возвращает AST C#-а которое описано в виде вариантных типов и классов (рядом в проекте).
M>возникает вопрос: что конкретно мы имеем на выходе? Дерево с "универсальными" узлами? Или произвольными, но с заданными интерфейсами? Тут хотелось бы чуть подробнее, т.к. инфа напрямую относится к парсеру.
Хотелось бы еще понять, что тебе хочется понять. Наверно проще будет просто посмотреть имеющиеся парсеры и попробовать сделать свой.
M>Одно дело — готовые примеры (не факт, что идеальные), другое — пояснение, почему сделано именно так. Да, вторая статья практически просится!
Вот я и говорю — надо писать отдельные статьи. Это все же общая документация, а не популярная статья.
M> Да, шарп сильно отстаёт в плане макросов. Возможно, немерлистам такое замечание нафик не нужно, но я бы это упомянул в "мягких недостатках" — возможность работы только с Немерле.
Это и упомянуто:
Кроме того, к недостаткам PegGrammar можно отнести способ его реализации (в виде макроса Nemerle). Но, во-первых, недостатком это является только для тех, кто по каким-то причинам не приемлет Nemerle, а во-вторых, полученный парсер можно использовать из любого .NET-языка, что делает его применение не страшнее, чем применение любого построителя парсеров кодогенерирующего типа (например, ANTLR).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, matumba, Вы писали:
M>А почему тогда предъявляется требование к возвращаемым типам? Не, отдалённо я понимаю, что генерируется AST, но т.к. ни одного реального дерева не видел, возникает вопрос: что конкретно мы имеем на выходе? Дерево с "универсальными" узлами? Или произвольными, но с заданными интерфейсами? Тут хотелось бы чуть подробнее, т.к. инфа напрямую относится к парсеру.
То что укажем в грамматике:
[PegGrammar(start, {
...
...
...
start : Email = username '@' hostname; // тут мы указываем, что из правила start — начального — выходит объект класса Email
})
]
class EmailParser
{
...
Start(username : UserName, hostname : HostName) : Email // у правил username и hostname типы соответственно UserName и HostName
{
CreateEmailFrom(username, hostname); // возвращается объект типа Email
}
...
}
Дисклеймер: парсера имейлов у нас в сниппетах еще нету, так что это я от фонаря написал.
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, matumba, Вы писали: M>>что конкретно мы имеем на выходе?
C>То что укажем в грамматике: C> Start(username : UserName, hostname : HostName) : Email // у правил username и hostname типы соответственно UserName и HostName
С е-мэйлом слишком просто. А компилятор? Мы возвращаем некий "синтаксический узел", правильно? Тогда вопрос: как узлы связываются в дерево? Ведь парсер просто говорит "такое-то правило разобрано".
Здравствуйте, matumba, Вы писали:
M>С е-мэйлом слишком просто. А компилятор? Мы возвращаем некий "синтаксический узел", правильно? Тогда вопрос: как узлы связываются в дерево? Ведь парсер просто говорит "такое-то правило разобрано".
"По индукции". Если некоторое правило разобрано — значит разобраны под-правила из которых оно состоит, а значит их обработчики вернули узлы, из которых можно собрать узел более высокого уровня. Тем самым дерево собирается снизу вверх — от листовых узлов, к корню (стартовому правилу).
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, catbert, Вы писали:
C>>Здравствуйте, matumba, Вы писали: M>>>что конкретно мы имеем на выходе?
C>>То что укажем в грамматике: C>> Start(username : UserName, hostname : HostName) : Email // у правил username и hostname типы соответственно UserName и HostName
M>С е-мэйлом слишком просто. А компилятор? Мы возвращаем некий "синтаксический узел", правильно? Тогда вопрос: как узлы связываются в дерево? Ведь парсер просто говорит "такое-то правило разобрано".
Если тебе нужно дерево в виде некоторой структуры данных, то его необходимо собрать самому, реализовав сборку в обработчиках.
Здравствуйте, Ka3a4oK, Вы писали:
M>>С е-мэйлом слишком просто. А компилятор? Мы возвращаем некий "синтаксический узел", правильно? Тогда вопрос: как узлы связываются в дерево? Ведь парсер просто говорит "такое-то правило разобрано".
KK>Если тебе нужно дерево в виде некоторой структуры данных, то его необходимо собрать самому, реализовав сборку в обработчиках.
Это я и спрашивал: КАК в _независимых_ коллбэках, которые принимают только разобранные куски текста, узнать, где нужно прицепиться в дерево? Возможно, я не знаю какой-то тонкости построения, давайте тогда примером:
"1 + 2 * 3"
Вот кусочек грамматики из CalcParser.n:
mulOrDiv : int = simplExpr (('*' / '/') spaces simplExpr)*;
sumOrSub : int = mulOrDiv (('+' / '-') spaces mulOrDiv )*;
start : int = spaces sumOrSub !any;
Допустим, разобрался "2*3", вызвался мой mulOrDivHandler с параметрами 2, '*', 3; (а мы строим АСТ) Ну сделаю я кусочек ветки 2 -> '*' <- 3, куда мне её девать?
M>mulOrDiv : int = simplExpr (('*' / '/') spaces simplExpr)*;
M>sumOrSub : int = mulOrDiv (('+' / '-') spaces mulOrDiv )*;
M>start : int = spaces sumOrSub !any;
M>
M>Допустим, разобрался "2*3", вызвался мой mulOrDivHandler с параметрами 2, '*', 3; (а мы строим АСТ) Ну сделаю я кусочек ветки 2 -> '*' <- 3, куда мне её девать?
Вернуть из обработчика. Дерево строится снизу вверх по мере разбора правил. Если некоторое правило отказывается, то автоматом выбрасываются все узлы AST, полученные из подправил, если правило разобрано, то его узел AST будет включать все узлы под-правил.
Здравствуйте, matumba, Вы писали:
M>Я верну, а куда оно завернётся? Сам PEGParser построит дерево из моих возвращаемых объектов, так?
Ты сам и звернешь — в другом обработчике, в конечном счете получится дерево. Рекурсия-с. Рекомендую посмотреть прасер Json-а, он несложный и с построением AST.
Здравствуйте, hardcase, Вы писали:
M>>Я верну, а куда оно завернётся? Сам PEGParser построит дерево из моих возвращаемых объектов, так?
H>Ты сам и звернешь — в другом обработчике, в конечном счете получится дерево. Рекурсия-с. Рекомендую посмотреть прасер Json-а, он несложный и с построением AST.
Всё, кажется понял (хотя исходники для понимания ничего не дают). Допустим, есть "1 + 2 * 3", тогда при свёртке "2 * 3" вызовется мой хэндлер умножения, в котором я верну (парсеру!) двухветочный узел АСТ "2 / * \ 3", а этот узел парсер подсунет (на след. итерации) хэндлеру сложения на месте второго аргумента (первым будет ещё не разобранная "1"). Не, товарищи, такие вещи категорически надо описывать — бессмысленно рассуждать о парсерах, если даже непонятно, кого и куда засовывать. Думаю, это пояснение надо в статью Влада — пусть и разжёвано, но это лучше недомолвок.
Здравствуйте, matumba, Вы писали:
M>Всё, кажется понял (хотя исходники для понимания ничего не дают). Допустим, есть "1 + 2 * 3", тогда при свёртке "2 * 3" вызовется мой хэндлер умножения, в котором я верну (парсеру!) двухветочный узел АСТ "2 / * \ 3", а этот узел парсер подсунет (на след. итерации) хэндлеру сложения на месте второго аргумента (первым будет ещё не разобранная "1").
Что-то вроде. Только это не обязательно будет АСТ. Это может быть и, например, вычисленное значение умножения, если речь идет о калькуляторе.
M>Не, товарищи, такие вещи категорически надо описывать — бессмысленно рассуждать о парсерах, если даже непонятно, кого и куда засовывать. Думаю, это пояснение надо в статью Влада — пусть и разжёвано, но это лучше недомолвок.
Это настолько базовые вещи, что ты первый у кого возник вопрос. Ну, или остальные боятся признаться в том, что ничего не поняли.
В любом изложении приходится опираться на некоторый базис. Иначе получится море воды и никакого толка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Что-то вроде. Только это не обязательно будет АСТ. Это может быть и, например, вычисленное значение умножения, если речь идет о калькуляторе.
Вот когда я понял, куда девается результат, тогда стали понятны фразы "можно возвращать вычисленное значение" — заметь, что в "теории парсеров" нет про это ни слова, это сугубо ПЕГовая частная реализация (где я вообще рассчитывал на автоматическое построение дерева).
VD>Это настолько базовые вещи, что ты первый у кого возник вопрос. Ну, или остальные боятся признаться в том, что ничего не поняли.
"Базового" много чего есть, например "6NF", но ведь ты же не с неё начал изучение СУБД? (про СУБД — подсказка ) Т.е. люди с примерным представлением о парсерах должны как-то въезжать в тему, тем более ты описываешь уже готовую реализацию (считай, новую библиотеку со своим API).
На это можно не отвечать, я просто даю рекомендации к статье.
Здравствуйте, matumba, Вы писали:
M>Вот когда я понял, куда девается результат, тогда стали понятны фразы "можно возвращать вычисленное значение" — заметь, что в "теории парсеров" нет про это ни слова, это сугубо ПЕГовая частная реализация (где я вообще рассчитывал на автоматическое построение дерева).
Не, не замечу. Все построители парсеров, в этом плане, работают одинаково. Только обычно результат накапливается в переменных, а мы передаем их через параметры.
Парсинг — это древесно-рекурсивный подход. Не понимая этого двигаться дальше нельзя.
VD>>Это настолько базовые вещи, что ты первый у кого возник вопрос. Ну, или остальные боятся признаться в том, что ничего не поняли.
M>"Базового" много чего есть, например "6NF", но ведь ты же не с неё начал изучение СУБД? (про СУБД — подсказка ) Т.е. люди с примерным представлением о парсерах должны как-то въезжать в тему, тем более ты описываешь уже готовую реализацию (считай, новую библиотеку со своим API). M>На это можно не отвечать, я просто даю рекомендации к статье.
Предполагалось, что человек должен иметь базовые представления о парсинге и конкретно о парсинге метдом рекурсивного спуска (на описание которого дана ссылка).
ЗЫ
В общем, я не против расширения статьи и введения туда пояснений. Но я не очень понимаю на каком уровне нужны эти пояснения. Проще всего было бы если, например, ты предложил бы вариант текста который ты хотел бы видеть в статье.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не, отдалённо я понимаю, что генерируется AST, но т.к. ни одного реального дерева не видел, возникает вопрос: что конкретно мы имеем на выходе? Дерево с "универсальными" узлами? Или произвольными, но с заданными интерфейсами? Тут хотелось бы чуть подробнее, т.к. инфа напрямую относится к парсеру.
