Парсинг с продолжениями

Не совсем то, что ты ищешь, ибо это решение позволяет составить парсер в коде с помощью декларативной записи аля ebnf. Но вроде бы умел так boost::spirit. По крайней мере я видел mpi систему на нём которая кушала сообщения из tcp сокета, а вот был ли там splitter или нет - хоть убей не помню.

Другое дело, что, обычно для этого таки используют сущность splitter, что бы разбить поток на сообщения, а потом кормить сообщения парсеру.

В Хаскеле есть пара таких либ (тот же attoparsec).

Строки скармливаешь хитрому потоку, поток - парсеру. Для потока реализуешь логику хитрой аппликации строк как тебе хочется.

Хитрый поток проще всего сделать на корутинах и прочих yield. Но, это слегка некрасиво, да и не особо эффективно, плюс из пушки по воробьям.

Тут уж выбирай эффективный парсер или эффективный поток.

man sed

man awk

Зачем выбирать, когда можно оба два. Вручную так точно.

ragel?

В Яре такой был. Стек такой:

1. Путём форка интерпретатора sb-eval из sbcl был сделан интерпретатор CL, способный прерваться и вернуть состояние.

2. Многоверсионные данные. Смысл тот же, что и в СУБД с многоверсионностью (Oracle/Postgres), но хранимые объекты имитируют консы, структуры и массивы.

3. В сумме (1) и (2) дают основу.

4. «Полностью кешированный поток» - это погружение потока (stream) в функциональную парадигму. Такой поток можно клонировать в любой точке и это будет как бы закладка, к которой можно вернуться и начать заново. И он нормально сочетается с интерпретатором из первой части.

5. На основе этого написана библиотека создания парсеров методом рекурсивного спуска с дополнительными операциями «установить закладку» и «вернуться к закладке». Точно уже не помню.

Всё это использовалось некоторое время для IDE и для собственно транспилятора. Но было оно очень медленным и оказалось в итоге непригодным для этой задачи.

Все эти «синхрофазатроны» аля генераторы генераторов парсеров парсеров - одно разочарование :-) Рецепт: берёшь Си и пишешь парсер вручную :-)

Перловые регексы<токены<рулсы<грамматики - не то?

https://docs.perl6.org/language/grammars

Не очень понятно описано, но выглядит так как будто вам нужен генератор pull-mode парсера. Если целевой язык С, то lemon ( https://www.hwaci.com/sw/lemon/lemon.html ) так умеет. Даете ему на вход по одному токены, он парсит и в семантических действиях изменяете состояние.

Или может быть вам нужно ввести в грамматику токен «перенос строки» и переписать логику с явным указанием окончания строки

Для этого есть монады и стрелки - слова, которые так не любят некоторые камрады. Сами же конструкции создают вычисления в рамках некоторого контекста. То есть, контекстом здесь будет собственно сам процесс парсинга, а значением внутри вычисления - нужное нам состояние. Все откаты происходят автоматически. Кое-где можно и закешировать результаты работы парсера для ускорения процесса.

Про одну из библиотек на haskell был пост выше.

Да, это возможно в Red, parse может выполнять произвольный код в процессе парсинга и этот код может менять сами правила парсинга.

Только это не как парсер генератор а просто парсер.

Давай пиши эффективный парсер с потоком (с семантикой). Только смотри, если грамматика не сложнее регулярок, твой парсер с потоком был конечным автоматом.

Ты так говоришь,как будто это рокетсайнс.

не распарсил

Жду регулярки с семантикой на конечных автоматах.

Это неявно делает любой токенайзер (например, flex). Как правило, они поступают значительно проще: в качестве состояния тебя просят предоставить им часть строки, которая подавалась на вход.

Не могу не пропиарить замечательный ragel: http://www.colm.net/open-source/ragel/. В мануале тебя будет интересовать глава 6.3 Scanners.

Жди.

«Жди» - хороший ответ эффективного разработчика

Для хороших людей, хороших ответов не жалко.

У эффективного разработчика на эффективный диалог ресурсов не жалко, эффективное использование ресурсов.

насколько помню «элементарная» связка bison+flex позволяет восстановить состояние при ошибке разбора и например начать скармливать ввод в другую грамматику. Про bison могу ошибаться, но flex точно можно откатывать при неверной лексеме.

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

да, надо делать буферизацию ввода на возможную глубину ошибки и прочие прелести, но всё возможно

можно простой пример,для арифметических,выражений в скобках,например?

а не изобретаешь ли ты https://en.wikipedia.org/wiki/Backtracking ?

можно простой пример,для арифметических,выражений в скобках,например?

как догадываешься, специально для ответа на ЛОР, довольно объёмный код писать не буду :-)

посмотри маны - обрати внимание что на каждом токене int YYSTATE - текущее состояние лексера, состояния можно менять yy_push_state yy_pop_state, затолкать обратно символ в поток yyunput, а сам поток FILE * и его тоже можно менять.

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

Но, ты же говоришь про восстановление после ошибки нет? А ТС, как я понял, ищет возможность «докармливать» парсер, если сообщение пришло не целиком.

как догадываешься, специально для ответа на ЛОР, довольно объёмный код писать не буду

Я думал может в доке чего есть.

А ТС, как я понял, ищет возможность «докармливать» парсер, если сообщение пришло не целиком.

Вроде того. Главное это объект состояния. Вот если у нас правило парсинга в виде regexp'а «file» после парсинга строки «fil» должен вернуться объект состояния. После парсинга строки «e some text» с сообщением того объекта состояния парсер должен найти соответствие правилу.

результат работы парсера был бы такой же как если бы парсера изначально бы отправили по одной строке, которая была бы соединением первой и новой строк

Вопрос: почему нельзя сразу скормить соединение этих двух (трёх, миллиона) строк? Соединить в ленивом стиле, конечно (сделать поток данных)

В случае ленивого(я так понимаю блокирующего) потока, довольно сложно делать производительные однопоточные многоклиентные сервера на основе очередей подсистемы ввода вывода операционки. Если честно без реализаций переключения контекста вручную, читай корутин и тому подобного, лично я сходу не могу придумать как это можно было бы реализовать. Вот только переключать самолично весть стейт потока, вместо вменяемого интерфейса парсера и переключения контекста только парсера выглядит слегка избыточно. Как и добавлять потоки(threads) и переключения контекста туда, где без этого можно обойтись и даже, до определённого момента, выиграть на отсутствии нескольких потоков.

А ТС, как я понял, ищет возможность «докармливать» парсер, если сообщение пришло не целиком.

на каждом токене получая состояние и используя на входе FILE * можно «кормить» парсер чем угодно. Пайпы никто не отменял, да и набор опций для парсинга из различных кусков во flex полно. Читайте маны - они рулят :-) info ещё знатная вещь - там как правило всё разжёвано детальнее и с примерами.

насколько понял ТС хочет нечто готовое, чтобы ничего не думать самому, но такого не бывает

В хаскеле нет продолжений

Как я понял из топика, ТС не имел в виду продолжения в смысле схемовских continuations.

А, так понятнее. Такая проблема решается конечным автоматом (man алгоритм ахо корасик).