Здравствуйте, samius, Вы писали:

S>В общем случае ПЕГ-у достаточно ленивого списка символов, который легко посадить на поток данных. Лишь в худшем случае размер данных, необходимых парсеру, будет равен длине потока.

Вот только не надо мне рассказывать о том в чем я разобрался .

ПЕГ в общем-случае обеспечивает неограниченное заглядывание вперед с помощью предикатов и откат вплоть до начала разбираемого "файла". На практике, конечно заглядывание и откат редко бывает очень глубоким. Но на то он и общий случай, чтобы нельзя было делать предположений.

Потом алгоритмы лежащие под ПЕГом оперируют с позицией в тексте. Это куда эффективнее чем возня с абстракциями (не нужным в данном случае раз все равно работа идет с индексами).

S>А вот его частные реализации как правило используют сразу все данные.

Они потому и используют, что базовая концепция подталкивает. Попытка работать не индексируемым представлением, а с некоторой абстракцией списка (с последовательным чтением) резко усложнит реализацию парсера и мало что даст взамен (ведь возможность откатиться в начало разбираемого текста есть всегда). По сути любой неудачный разбор приводит к полному откату парсера (если нет дополнительных средств останова отката).

Здравствуйте, fddima, Вы писали:

VD>>Возвращать. Делается две функции Peek() и Read(). Первая возвращает сивол не меняя позиции (заглядывание вперед на единицу), вторая сдвигая позицию на единицу. Реализуется все очень просто:
F> Это всё понятно. Далее то куда их девать?

Что значит куда девать? Их достаточно для реализации разбора на базе, например, конечного автомата.

VD>>XML ни чуть сложнее, а намного сложнее, так как грамматика у него не регулярная. Тут уже одним конечным автоматом не обойтись. По любому нужен стек, а лучше полноценный построитель парсеров.
F> Не особо нужен.

Ну, спорить с теорией можно, но глупо .

F>>> Как насчёт замерить скорость стандартного дотнетовского XML парсера с твоим пеговым?
VD>>Мне просто в лом тратить время на пенесометрию, но на результаты взглянул бы с удовольствием. Если займешься, я буду тебе очень благодарен.
F> Мне тоже в лом, но интересно. Я не знаю что где и как с твоим парсером. Где можно посмотреть?

Мой парсер не был предназначен для пенисометрии. Он был разработан в рамках макроса предоставляющего XML-литералы в виде DSL для Nemerle (весь проект можно посмотреть здесь, там же есть и тесты демонстрирующие использование). Но из него не сложно будет выдрать грамматику, убрать расширения и сделать тестовый парсер.

VD>>>>Ну, практика показывает, что грамотно сгенерированный парсер может быть и быстрее рукописного. Вот товарищ пишет

Автор: Ziaw
Дата: 02.12.10

, что его ПЕГоский парсер JSON-а в полтора раза быстрее аналогичного рукописного написанного по всем канонам. При этом он писал парсер всего 3 часа.
F>>> Тоже самое относится к рукописным. О чём тут спорить?
VD>>Что относится? Ты внимательно прочитал написанное мной?
F> Внимательно. Говорю, что тоже можно сказать о рукописных парсерах: грамотно написанный и т.д. может быть и т.д.
F> Что касается Json — думаю это всё же недостаток самого newton. И преимущество вашей реализации PEG, если всё так просто получается делать как ты говоришь.

Я смотрел newton — это добротный рукопашный парсер в котором все хорошо кроме того, что в нем местами используются абстракции которые с одной стороны необходимы чтобы не превратить код парсера в ужасное говнище, но с другой не могут не влиять (негативно) на производительность.

Преимущество генерированного кода в том, что он может плевать на абстрации и быть сколь угодно ужасен. Более того. Генерируемый код может быть одновременно и ужасен, и приличным (пригодным для отладки). Например, наш PegGrammar генерирует весьма читабельный код в дебаг-версии проекта, и высокооптимизированный в релизе. В релизе производится ряд хардкорных оптимизаций (генерация ДКА, переписывание правил и т.п.), а дебаге наоборот делаются преобразования направленные на упрощение генерируемого кода.

Как ты понимаешь, рукописный парсер себе такого позволить не может.

Ну, и совершенно очевидно, что генерированный код может плевать на абстракции просто потому, что исходным кодом для парсера является грамматика и обработчики, а не сам парсер, как в случае рукописного парсера.

Лично я никогда не написал бы такого кода который генерирует PegGrammar, так как его было бы невозможно поддерживать. Но поддержка макроса сводится к поддержке алгоритмов оптимизации и генерации кода. А поддержка конечного парсера в правке грамматики. Посему можно допускать чудовищный с точки зрения рукописного кода код, но при этом высокопроизводительный.

Один факт. В Nemerle нет оператора goto, но внутри макросов такой код все же сгенерировать можно. И PegGrammar этим во всю пользуется при генерации конечных автоматов в релиз-версии. Применение goto дало где-то 10% прироста производительности конечного парсера. Такое применение goto вполне оправданно. Но в рукописном коде я бы ни в жизнь не допустил бы использования goto.

Я конечно не утверждаю, что невозможно создать рукописный парсер которые был бы эффективнее генерированного. Это не так. Но при прочих равных — это не такая уж простая задача.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:

S>>В общем случае ПЕГ-у достаточно ленивого списка символов, который легко посадить на поток данных. Лишь в худшем случае размер данных, необходимых парсеру, будет равен длине потока.

VD>Вот только не надо мне рассказывать о том в чем я разобрался .
Зато я не разобрался. Но я разбирался с парсер-комбинаторами, и не вижу здесь препятствий для работы с ленивой структурой данных, кроме разве что эффективности.

VD>ПЕГ в общем-случае обеспечивает неограниченное заглядывание вперед с помощью предикатов и откат вплоть до начала разбираемого "файла". На практике, конечно заглядывание и откат редко бывает очень глубоким. Но на то он и общий случай, чтобы нельзя было делать предположений.
нет возражений

VD>Потом алгоритмы лежащие под ПЕГом оперируют с позицией в тексте. Это куда эффективнее чем возня с абстракциями (не нужным в данном случае раз все равно работа идет с индексами).
да, эффективнее.

VD>Они потому и используют, что базовая концепция подталкивает. Попытка работать не индексируемым представлением, а с некоторой абстракцией списка (с последовательным чтением) резко усложнит реализацию парсера и мало что даст взамен (ведь возможность откатиться в начало разбираемого текста есть всегда). По сути любой неудачный разбор приводит к полному откату парсера (если нет дополнительных средств останова отката).
Позиция в буфере и есть та самая абстракция. Просто в каких-то реализациях она выражена как индекс, в других как char*, в третьих — узел ленивого списка.

Если PEG-у не требуется random-access к разбираемой строке, то он так же как и парсер-комбинатор сможет работать с другой абстракцией без увеличения алгоритмической сложности. То что вырастет кол-во тактов — не спорю. И даже с тем что это нафиг не надо — тоже не спорю.
Я докопался лишь с мыслью, что требование загрузки всех данных — лишь специфика реализации/большинства реализаций/быстрых реализаций, а не PEG-а как такового.
Впрочем, допускаю, что и ошибаюсь. Т.к. с PEG не знаком даже поверхностно.

Здравствуйте, samius, Вы писали:

S>Зато я не разобрался. Но я разбирался с парсер-комбинаторами, и не вижу здесь препятствий для работы с ленивой структурой данных, кроме разве что эффективности.

С ленивыми структурами данных всегда так. Всем они хороши кроме медлительности и непредсказуемости .

Как я уже говорил проблема в откатах и заглядывании. Для эффективной самый лучший способ — это работа с индексами и соответственно массивами (строка в дотнете тоже массив своего рода). При этом откаты на начало текста стоят точно столько же сколько на пару символов.

Вообще было бы интересно посоревноваться с комбинаторными парсерами в скорости. Теоретически, на реальных задачах, мы (PegGrammar) должны порвать их как Тузик грелку. Но теория, есть теория. А хорошо бы это удивить на практике.

VD>>Они потому и используют, что базовая концепция подталкивает. Попытка работать не индексируемым представлением, а с некоторой абстракцией списка (с последовательным чтением) резко усложнит реализацию парсера и мало что даст взамен (ведь возможность откатиться в начало разбираемого текста есть всегда). По сути любой неудачный разбор приводит к полному откату парсера (если нет дополнительных средств останова отката).
S>Позиция в буфере и есть та самая абстракция. Просто в каких-то реализациях она выражена как индекс, в других как char*, в третьих — узел ленивого списка.

Индекс и указатель (в сишном его понимании) эквивалентны. А вот "узел ленивого списка" — это извините лажа... с точки зрения скорости. Ведь эти узлы придется лепить на каждый символ. Даже при дико-эффективном GC эта операция очень дорогая. А в дотнете GC не так эффективен, так как рассчитан на императивные языки и на много поточный доступ (да и вообще далек от идела). Так что я не поставил бы на такую реализацию и трех рублей.

S>Если PEG-у не требуется random-access к разбираемой строке, то он так же как и парсер-комбинатор сможет работать с другой абстракцией без увеличения алгоритмической сложности.

На самом деле PEG — это не алгоритм, а нотация. Так что в принципе его можно разбирать и на основе парсер-комбинаторов с ленивыми списками под копотом. Просто когда код генерируется, то столь не эффективные реализации откидываются сами собой. Это на хаскеле другие пути слишком сложны, вот и лепят все в виде комбинаторов. Плюс хаскель все же не хилые оптимизации обеспечивает. А в дотнете их нет и появятся ли они ил нет неизвестно. Рассчитывать на них просто не серьезно. Зато мы можем использовать "грязную силу". Абстракция у нас обеспечивается декларативной грамматикой (которая хаскелям разным 100 очков форы даст) и генератором кода. Вот и падет выбор на массивы (строки), индексы и разные goto.

S>То что вырастет кол-во тактов — не спорю. И даже с тем что это нафиг не надо — тоже не спорю.
S>Я докопался лишь с мыслью, что требование загрузки всех данных — лишь специфика реализации/большинства реализаций/быстрых реализаций, а не PEG-а как такового.

Ну, в общем — да. Конечно если представлять вычисления и данные в виде ленивых списков, то можно обойтись без массивов и индексов. Но такая реализация уже будет сильно уступать ручной реализации на основе конечных автоматов. Так что никакого выигрыша (кроме декларативности) от использования PEG-а не будет.

S>Впрочем, допускаю, что и ошибаюсь. Т.к. с PEG не знаком даже поверхностно.

PEG — это не более чем красивая нотация для описания рекурсивных парсеров с откатами. Так что если ты знаком с комбинаторными парсерами, то свитай, что знаком и с базовыми алгоритмами реализации PEG-а. А сама грамматика PEG-а очень похожа на скрещивание ужа с ежом, т.е. на скрещивание регулярных выражений и BNF. Основных новшеств два:
1. Оператор приоритетный выбора "/" вместо перечисления "|". Он как бы говорил, что если у нас есть правило А и Б перечисленные через этот оператор — "А / Б", то будет по очереди произведена попытка сопоставить оба этих правила. Причем если правило А сопоставится, то попытка сопоставлять Б даже не будет предприниматься. И соответственно, если попытка разобрать входную стоку по правилу А обломается, то будет предпринята попытка разобрать правило Б. Соответственно, если попытка будет успешным, то ОК, иначе разбор всего общего правила будет читаться проваленным.
2. Есть операторы предикатов "&" и "!". Они позволяют проверить сопоставиться ли в текущей позиции текст с правилом идущим за предикатом или нет. Первый позволит продолжить разбор текущего правила если идущее следом правило сопоставилось, второй наоборот. Например, с предикатом разобрать сишный комментарий можно очень простым правилом: "/*" (!"*/" any)* "*/"

Здравствуйте, VladD2, Вы писали:

VD>Как я уже говорил проблема в откатах и заглядывании. Для эффективной самый лучший способ — это работа с индексами и соответственно массивами (строка в дотнете тоже массив своего рода). При этом откаты на начало текста стоят точно столько же сколько на пару символов.

Да, и откат на узел списка будет стоить ровно столько же, пока не потребуется откат на позицию между (текущей и началом)/2. Но насколько я представляю себе кухню — не потребуется.

VD>Вообще было бы интересно посоревноваться с комбинаторными парсерами в скорости. Теоретически, на реальных задачах, мы (PegGrammar) должны порвать их как Тузик грелку. Но теория, есть теория. А хорошо бы это удивить на практике.
У меня под рукой парсер-генератор на C++, для которого я реализовал XML и еще кое-что, срезав пару углов из спеки для достижения скорейшего результата. Оптимизацией и замерами времени не занимался, но по ощущениям мегабайта 4 за секунду проглатывать должен. Кстати, поток данных у него на const wchar_t*.
Если хочется посорвеноваться — вот ссылка на тему

Автор: Schade
Дата: 22.02.08

где комбинаторные парсеры фигурируют. Правда, бенчмарк не очень интересный — поток double-ов.

VD>Индекс и указатель (в сишном его понимании) эквивалентны. А вот "узел ленивого списка" — это извините лажа... с точки зрения скорости. Ведь эти узлы придется лепить на каждый символ. Даже при дико-эффективном GC эта операция очень дорогая. А в дотнете GC не так эффективен, так как рассчитан на императивные языки и на много поточный доступ (да и вообще далек от идела). Так что я не поставил бы на такую реализацию и трех рублей.
+1

VD>Ну, в общем — да. Конечно если представлять вычисления и данные в виде ленивых списков, то можно обойтись без массивов и индексов. Но такая реализация уже будет сильно уступать ручной реализации на основе конечных автоматов. Так что никакого выигрыша (кроме декларативности) от использования PEG-а не будет.
Согласен. Если упор на скорость, то индекс/указатель — оптимальное решение. Указатель на узел позволит читать потенциально бесконечные тексты, но значительно медленнее и лишь в случаях ограниченных откатов (все узлы между текущим и тем, на который откатываемся должны уложиться в памяти).

VD>PEG — это не более чем красивая нотация для описания рекурсивных парсеров с откатами. Так что если ты знаком с комбинаторными парсерами, то свитай, что знаком и с базовыми алгоритмами реализации PEG-а. А сама грамматика PEG-а очень похожа на скрещивание ужа с ежом, т.е. на скрещивание регулярных выражений и BNF. Основных новшеств два:

Т.е. похоже что отличие PEG от комбинаторного парсера можно сформулировать так: PEG генерит код на основе нотации, в то время когда комбинаторные парсеры комбинируются непосредственно кодом и красота нотации ограничена синтаксисом используемого языка. Так, в чистом C++ (не 0x) приходится сильно карячиться без лямбд, замыканий и т.п. Результат получается еще менее декларативный, чем в haskell.

Здравствуйте, samius, Вы писали:

S>Да, и откат на узел списка будет стоить ровно столько же, пока не потребуется откат на позицию между (текущей и началом)/2. Но насколько я представляю себе кухню — не потребуется.

Можно реализовать все так, что и в случае списков откат на любой уровень будет стоить одинаково. Нельзя лишь сделать так, чтобы реализовав это не замедлить сам парсер. Еще раз повторюсь — список и тем более хранящий действия, а не только данные (ссылки на функции) — это очень не шустрый способ реализации. Да, скорость в нотации О будет та же, но реальная скорость будет низкой, так как выхлопу будет уходить в формирование списка для каждого символа.

VD>>Вообще было бы интересно посоревноваться с комбинаторными парсерами в скорости. Теоретически, на реальных задачах, мы (PegGrammar) должны порвать их как Тузик грелку. Но теория, есть теория. А хорошо бы это удивить на практике.
S>У меня под рукой парсер-генератор на C++, для которого я реализовал XML и еще кое-что, срезав пару углов из спеки для достижения скорейшего результата. Оптимизацией и замерами времени не занимался, но по ощущениям мегабайта 4 за секунду проглатывать должен.

Все конечно зависит от процессора. Но на Core 2 сгенерированный нашим макросом парсер выдает 4 метра на грамматике C# 4.0. Так что думаю, как минимум, медленнее не будет. Хотя, конечно, нужно пробовать.

S>Кстати, поток данных у него на const wchar_t*.
S>Если хочется посорвеноваться — вот ссылка на тему

Автор: Schade
Дата: 22.02.08

где комбинаторные парсеры фигурируют. Правда, бенчмарк не очень интересный — поток double-ов.

Я бы сказал совсем не интересный. Примитивные тесты не показательны. Там и откаты то не нужны вовсе. ХМЛ еще может и потянет, но тоже весьма простой формат. А лучше какой-нить язык программирования. Вот в грамматике шарпа без откатов никуда. Там и без предикатов то не обойтись. Одни неоднозначности с приведением типов или операторами ? : что стоят?

S>Т.е. похоже что отличие PEG от комбинаторного парсера можно сформулировать так: PEG генерит код на основе нотации, в то время когда комбинаторные парсеры комбинируются непосредственно кодом и красота нотации ограничена синтаксисом используемого языка. Так, в чистом C++ (не 0x) приходится сильно карячиться без лямбд, замыканий и т.п. Результат получается еще менее декларативный, чем в haskell.

Не совсем так, так как от нечего делать можно генерить и комбинаторне парсеры по PEG-грамматике, но это конечно дурь. Прелесть и убогость комбинаторных парсеров в их динамичности. С одной стороны можно легко менять грамматику на лету, но с другой и производительности оптимальной добиться невозможно, и ошибки в грамматике выявлять сложно, и вообще — код не самый удобный способ представления грамматик (даже в лисе или немреле).

Но в общем — да. PEG позволяет описать грамматику декларативно и дальше уже генерироваться на ее основе такую реализацию парсера какая нужна. Это скорее всего (процентов эдак на 99) окажется рекурсивный парсер с откатами, но нюансов там получается море. Тут тебе и представление данных, и мемоизация промежуточных вычислений и генерация ДКА и многое другое.

Что же касается выразительности хаскеля и С++, то по мне так они примерно равный. В хаскеле ДСЛ-и (а мы имеем дело именно с ними) делаются за счет манипулирования функциями. В С++ того же эффекта достигают с помощью мета-программирования на шаблонах (см. boost::Spirit). Оба способы несовершенны и значительно уступают полноценным макросам Лиспа и Немерла (особенно последнего, так как в немерле макры мощнее). Выше я уже приводил грамматику шарпа. Как видишь — это полностью декларативный стиль. Причем без компромиссов (как в случае хаскеля и С++). Но это еще не все! Мы имеем и и другие бенефиты:
1. Мы не ограничены в выборе алгоритмов. Сгенерировать можно хоть черта лысого. Хаватило бы мозгов чтобы все решение понять.
2. Наше решение интегрируется в IDE. Мы получаем такие фишки как навигация по правилам, внятные сообщения об ошибках в грамматиках и т.п.
3. Мы можем так же генерировать документацию и сопутствующие вещи.

Здравствуйте, Jolly Roger, Вы писали:

JR>Да нет никакой проблемы, тем более — с CSV Переносов, кстати, тоже, в CSV строка файла == строка таблицы. Просто читаете целиком одну строку в свой буфер и ходите по нему сколько угодно. Но необходимости в таком хождении в общем случае тоже нет. Даже читая посимвольно из однонаправленного потока, складываете символы в буфер, пока не обнаружите конец лексемы, а потом уже смотрите, что за лексема. Для кавычек и т.п. просто заведите ещё одно состояние, да и всё.

По поводу переносов строки уже сказали, но в остальном — так. Строка в кавычках — это один токен, то есть ещё одно состояние парсера (если делать его как FSM). Кстати парсеры на FSM не всегда хороши. Нас в универе учили писать рекурсивные лексеры — они обычно существенно проще. Например, с помощью флекса,бизона и файла описания грамматики простейший интерпретатор/компилятор языка С пишется за 3-4 часа (мы на лабах такое делали).

Здравствуйте, koandrew, Вы писали:

K>По поводу переносов строки уже сказали, но в остальном — так. Строка в кавычках — это один токен, то есть ещё одно состояние парсера (если делать его как FSM). Кстати парсеры на FSM не всегда хороши.
В данном случае парсер на ДКА прокатит.
У CSV грамматика регулярная.

K>Нас в универе учили писать рекурсивные лексеры — они обычно существенно проще.
Существенно проще чем что?

K>Например, с помощью флекса,бизона и файла описания грамматики простейший интерпретатор/компилятор языка С пишется за 3-4 часа (мы на лабах такое делали).
bottom-up parser тот еще геморой когда дело доходит до сообщений об ошибках.
Лучше использовать top-down parser. Особенно PEG. Ибо PEG умеет произвольные синтаксические предикаты что растягивает класс разбираемых языков аж до некоторого подмножества контекстно зависимых.

Здравствуйте, VladD2, Вы писали:

F>> Это всё понятно. Далее то куда их девать?
VD>Что значит куда девать? Их достаточно для реализации разбора на базе, например, конечного автомата.
Если это эээ литерал — каким образом мы его получим в виде строки?

F>> Не особо нужен.
VD>Ну, спорить с теорией можно, но глупо .
Не особо нужен полноценный построить парсеров. Стёк нужен — но он достаточно прост.

VD>Мой парсер не был предназначен для пенисометрии. Он был разработан в рамках макроса предоставляющего XML-литералы в виде DSL для Nemerle (весь проект можно посмотреть здесь, там же есть и тесты демонстрирующие использование). Но из него не сложно будет выдрать грамматику, убрать расширения и сделать тестовый парсер.
Я обязательно посмотрю, но позже. Надо сначала посмотреть что к чему, разобраться. Тут ещё сложность в том что от немерле я запускал только инсталлятор в лучшем случае год назад. Поэтому буду смотреть на код коровьими глазами.

VD>Один факт. В Nemerle нет оператора goto, но внутри макросов такой код все же сгенерировать можно. И PegGrammar этим во всю пользуется при генерации конечных автоматов в релиз-версии. Применение goto дало где-то 10% прироста производительности конечного парсера. Такое применение goto вполне оправданно. Но в рукописном коде я бы ни в жизнь не допустил бы использования goto.
Да, goto — рулит. И ими можно много чего выжать, но соглашусь что писать руками их затея как минимум не простая, да и выглядит странной.

VD>Я конечно не утверждаю, что невозможно создать рукописный парсер которые был бы эффективнее генерированного. Это не так. Но при прочих равных — это не такая уж простая задача.
А я не утверждаю что можно успешно написать любой рукопашный парсер. Речь о достаточно простых. XML тот же — тоже можно, но уже не просто.

Здравствуйте, samius, Вы писали:

S>У меня под рукой парсер-генератор на C++, для которого я реализовал XML и еще кое-что, срезав пару углов из спеки для достижения скорейшего результата. Оптимизацией и замерами времени не занимался, но по ощущениям мегабайта 4 за секунду проглатывать должен. Кстати, поток данных у него на const wchar_t*.
S>Если хочется посорвеноваться — вот ссылка на тему

Автор: Schade
Дата: 22.02.08

где комбинаторные парсеры фигурируют. Правда, бенчмарк не очень интересный — поток double-ов.

Как я уже говрил даблы конечно лажа а не тест. Но вот вам наш ответ чемберленам:
http://rsdn.ru/forum/decl/4070931.1.aspx

Автор: VladD2
Дата: 09.12.10

Так что рвем всех даже там где нет никаких причин это делать . Ну, а теперь сравни это дело со Штатным парсеком, что на тех самых списках на ленивых. Вот тебе и ответ на вопрос о том можно ли вместо индексов списки применять (ленивые).

Здравствуйте, VladD2, Вы писали:

VD>Как я уже говрил даблы конечно лажа а не тест. Но вот вам наш ответ чемберленам:
VD>http://rsdn.ru/forum/decl/4070931.1.aspx

Автор: VladD2
Дата: 09.12.10

VD>Так что рвем всех даже там где нет никаких причин это делать . Ну, а теперь сравни это дело со Штатным парсеком, что на тех самых списках на ленивых. Вот тебе и ответ на вопрос о том можно ли вместо индексов списки применять (ленивые).

Таки можно, если нужно. Еще раз напомню, что я не предлагал что-либо менять в текущей реализации. Просто упомянул о том, что необходимость загрузки всех данных в память — это специфика реализации, а не PEG-а как такового.
Если честно, я даже не могу высосать из пальца задачу с претензией на реальность, где бы данные для разбора не могли бы поместиться в памяти. Тот же бесконечный CSV выглядит по меньшей мере глупо, притом что гарантий его разбора парсер на ленивых списках дает не сильно больше.

Здравствуйте, samius, Вы писали:

S>Таки можно, если нужно. Еще раз напомню, что я не предлагал что-либо менять в текущей реализации. Просто упомянул о том, что необходимость загрузки всех данных в память — это специфика реализации, а не PEG-а как такового.

Теоретически — да. На практике при этом придется забить на производительность.

S>Если честно, я даже не могу высосать из пальца задачу с претензией на реальность, где бы данные для разбора не могли бы поместиться в памяти. Тот же бесконечный CSV выглядит по меньшей мере глупо, притом что гарантий его разбора парсер на ленивых списках дает не сильно больше.

Придумать пример элементарно. Например, разбор лога веб-сервера ведущегося в текстовом формате.

Здравствуйте, samius, Вы писали:

S>Таки можно, если нужно. Еще раз напомню, что я не предлагал что-либо менять в текущей реализации. Просто упомянул о том, что необходимость загрузки всех данных в память — это специфика реализации, а не PEG-а как такового.

Теоретически — да. На практике при этом придется забить на производительность.

S>Если честно, я даже не могу высосать из пальца задачу с претензией на реальность, где бы данные для разбора не могли бы поместиться в памяти. Тот же бесконечный CSV выглядит по меньшей мере глупо, притом что гарантий его разбора парсер на ленивых списках дает не сильно больше.

Придумать пример элементарно. Например, разбор лога веб-сервера ведущегося в текстовом формате.

Здравствуйте, VladD2, Вы писали:

S>>Если честно, я даже не могу высосать из пальца задачу с претензией на реальность, где бы данные для разбора не могли бы поместиться в памяти. Тот же бесконечный CSV выглядит по меньшей мере глупо, притом что гарантий его разбора парсер на ленивых списках дает не сильно больше.

VD>Придумать пример элементарно. Например, разбор лога веб-сервера ведущегося в текстовом формате.

Неудачный пример. "Бесконечный" лог спокойно парсится построчно.