Здравствуйте, 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>На это можно не отвечать, я просто даю рекомендации к статье.
Предполагалось, что человек должен иметь базовые представления о парсинге и конкретно о парсинге метдом рекурсивного спуска (на описание которого дана ссылка).
ЗЫ
В общем, я не против расширения статьи и введения туда пояснений. Но я не очень понимаю на каком уровне нужны эти пояснения. Проще всего было бы если, например, ты предложил бы вариант текста который ты хотел бы видеть в статье.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Но я прочитал начало и понял чем PEG отличается от BNF. Толково объяснена, без водички, левая рекурсия. Это важное знание, вне зависимости от языка программирования, платформы и т.д. То есть когда мне в следующий раз придётся создавать парсер на каком бы то ни было языке, с помощью какого бы то ни было инструмента, я с некоторой вероятностью загляну в твою статью. ИМХО это очень важно, когда в статьях есть не только сиюминутные конъюнктурные сведения, но и что-то более основополагающее и вечное. Так что твоя статья лично мне интересна, и спасибо тебе за неё. Вот.
Не, отдалённо я понимаю, что генерируется AST, но т.к. ни одного реального дерева не видел, возникает вопрос: что конкретно мы имеем на выходе? Дерево с "универсальными" узлами? Или произвольными, но с заданными интерфейсами? Тут хотелось бы чуть подробнее, т.к. инфа напрямую относится к парсеру.
