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

K>Так в C# версии проблем с промежуточными списками вроде как и нет. Там проблема в другом — код в котором много комбинаторов сам по себе ленивый, а средств для оптимизации такой ленивости в компиляторах strict языков по понятным причинам меньше, чем в GHC.

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

K>В том треде варианты на OCaml и F# также сливали Хаскелю.

Дык, хаскель действительно заточен под комбинаторы. Там на эту оптимизацию положиле добрых 10 лет жизни не одного человека.

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

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

VD>>2. Не верю! Не верю, что в 500. Даже не верю, что в 10 раз медленее, если алгоритмически они эквивалентны.

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

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

K>Я то всего навсего попрытался показать, что комбинаторы могут обходиться гораздо дроже, чем в десятки процентов и еденицы раз. Согласен, что у моего обоснования есть изъяны, но в общем случае, мое утверждение лучше обосновано, чем Ваше, которое никак не доказано и даже не проиллюстрировано.

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