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

VD>Я думаю, что проблема там в том, что создается множество промежуточных объектов.

Ну это-то как раз очевидно.

VD>Использование итераторов приводит к этому на раз.

Только итераторы тут непричем, эти "промежуточные" объекты — замыкания лямбд. Итераторы там использованы в незначительном количестве и потому, в основном, что рекурсия переполняет стек.

VD>Где-то пробигали варианты Парсека написанные на Немерле. Там вместо итераторов использовались лямбды. Правда, там для получения конца строки используется метод Substring(), но это легко лечится.
VD>Можно провести сравнения.

Ну так там так и есть — просто ситуация с Substring уже вылечена.

VD>Лучше скажи, сколько они сливают? Не уж-то 50 процентов?

Haskell — 16.83 мб/c на ГГц
OCaml (быстрый) — 8.0
F# (монадический) — 2.34
OCaml (монадический) — 1.9
C# (оптимизированный) — 0.75
C# (первоначальный) — 0.06

Т.е. разница везде в разы, а не на проценты. Учитывая то, что на настоящий момент этот компилятор Хаскеля уже допотопный.

VD>В прочем, в любом случае такой код никто в реальной жизни использовать не будет.

Ну с той скоростью, которую дает C# — естественно. А с той скоростью, что дает GHC — может и будет.

VD>Не, так дело не пойдет. Доказывать корректность результатов должен тот, то их предлагает.

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

VD>Дык это уже не совсем комбинаторы. Это еще и наворот на итераторах.

Да нет там никаких особенных наворотов на итераторах.

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

В том и дело, что алгоритм один — а разница существенная.