Комбинаторы парсеров на LINQ

[metaclass]

Таки дорвался использовать Monadic Parser Combinators. Достаточно удобно, можно думать категориями Parsec-а, но ошибки компилятора или стеки вызовов при рунтайм-ошибках выглядят ужасающе.
Кстати, по моему, там TValue[] в Rep и Rep1 надо на IEnumerable заменить

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

Теперь думаю, куда бы это контекст со списком парсеров(которые изменяются по ходу разбора) засунуть. Тут подсказали стрелки, но как оные стрелки впихнуть в дотнет и LINQ это отдельный вопрос. Наверно, имеет смысл список парсеров (вернее map идентификатор -> парсер) поселить вместе со входным списком токенов и наколбасить хитрых парсеров, которые кроме того, что потребляют токены, еще и меняют список.

Ну и еще совсем непонятно, как это все будет работать в отсутствие ленивости и оптимизации хвостовых вызовов.

Comments

[metaclass.livejournal.com]

Ага, разгадал. Что-то с утра как-то быстро понятно стало.

[guamoka.livejournal.com]

Угу. Меня порадовал нестандартный подход Б. Гейтса- просто запомнить комбинации. Я бы лично Билла проверил (на всякий случай): добавил бы еще пять костяшек и посмотрел, что он скажет;-)

[metaclass.livejournal.com]

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

[guamoka.livejournal.com]

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