Comments 5
Кроме того, для негативных прогнозов значение всегда будет None.Непонятно, из чего это следует. Что мешает генератору возвращать результат сопоставления под lookahead?
Как видно из приведённого выше фрагмента грамматики, lookahead не могут получить собственные имена. Это легко поправить, но я пока не представляю как бы это пригодилось.
Я собирался обсудить оператор «вырезать» (~), присутствующий в TatSu, но мне пока не довелось с ним столкнутся. Я не готов даже пока его обсуждать — документация TatSu приводит только простой пример, который меня мало интересует. Я не нашёл его и в других генераторах PEG-парсеров, так что, возможно, эта фича есть только TatSu. Может быть, я когда-нибудь расскажу и про него. (Тем временем я его реализовал на всякий случай, мало ли. :-)
Странная логика. Т.е. реализовать оператор, который просто вообще нарушает саму логику PEG (отключая выбор альтернатив — см. описание) — это нормально, а то, что не нарушает, зато логично вписывается в концепцию — "не представляю как бы это пригодилось". Странная логика.
Вообще, чувак занимается пилением велосипедов со странным подходом. То вместо использования повторений борется с левой рекурсией (вообще надуманная проблема — зачем тебе тут рекурсия, когда это повторение в чистом виде?). То для использования меток у правил генерирует их из имен правил. А если тебе нужна метка для не для куска правила, а для некоей группы, как здесь:
start = ('a' 'b' 'с') { ??? }В этой статье он похоже заглянул в другие реализации и пришел к идее явных меток, но что мешало сделать это раньше?
Как я понял, он собирается это использовать в проде. Ну посмотри тогда, как другие реализовали — pegjs, например. Стройная, красивая реализация. Можно написать плагин, чтобы генерил Python код. Да даже в качестве бутстрапа можно просто взять и вручную преобразовать сгенерированный JS в Python (я так делал, когда мне быстро понадобился парсер на питоне, т.к. это оказалось быстрее, чем написать новый плагин генерации. Грамматика была небольшая и развиваться не будет).
Например, сразу начал использовать мемоизацию, а это может привести к тому, что сообщения об ошибках иногда будут некорректными — см. pegjs#612. Конечно, возможно, что в грамматике питона таких случаев нет, но тогда возникает вопрос — зачем писать свой генератор, когда готовых полно? В качестве упражнения нормально, но тащить в прод?
Странная логика. Т.е. реализовать оператор, который просто вообще нарушает саму логику PEG (отключая выбор альтернатив — см. описание) — это нормально,Эм, ну вот как раз он и не реализовал оператор `cut` (который отключает альтернативы), т.к. пока нет необходимости.
Более чем уверен, что автор посмотрел не одну реализацию PEG, прежде чем приступить к работе (по крайней мере он на них иногда ссылался). Тащить же js библиотеку в ядро python по мне так выглядит уж слишком безумным, но не отрицаю, что оттуда можно взять идеи. Тем более `PEG.js is still very much work in progress. There are no compatibility guarantees until version 1.0`.
Для негативных прогнозов Гвидо всегда возвращает None, это одна из аксиом.
Аксиом чего? Прогнозы возвращают True или False. Сейчас технически это сделано через возврат значения или None, но никто не мешает сделать по-другому.
Тащить же js библиотеку в ядро python по мне так выглядит уж слишком безумным, но не отрицаю, что оттуда можно взять идеи.
Никто не предгалает тащить js. Можно было сгенерировать начальный парсер для питона этой библиотекой, а потом уже, имея на руках этот парсер, он сам себя бы смог генерировать. Так как писать плагин к JS-библиотеке ради единственного использования было бы глупо, то можно было бы сгенерировать код на JS а потом вручную перевести его на Python — там почти 1-в-1 получается.
Тем более PEG.js is still very much work in progress. There are no compatibility guarantees until version 1.0.Вы не смотрите на это, она настолько stable, что мне не удалось пробить автора смерджить реализацию парсера повторений, хотя она готова уже лет 6. За это время автор уже успел потерять интерес к проекту, передал его другому мейнтейнеру и проект, к сожалению, окончательно слился.
Более чем уверен, что автор посмотрел не одну реализацию PEG, прежде чем приступить к работе
Ну вот не похоже по его статьям. В процессе написания — очень может быть. А до этого все статьи — жуткое велосипедостроение.
Эм, ну вот как раз он и не реализовал оператор cut (который отключает альтернативы), т.к. пока нет необходимости.Ну он же прямо специально в скобках написал, а я процитировал, что
(Тем временем я его реализовал на всякий случай, мало ли. :-)
Что же касается реальной смены парсера — давайте подождём хотя бы черновика PEP. Там и можно будет продолжить обсуждения. Мне же не удалось найти пока кода, который Гвидо хочет влить в CPython.
Реализация остальных возможностей PEG