какие-то энергичные листы

[stdray]

Почему в F# и Nemerle списки, которые в коробке, являются энергичными, ведь с их помощью нельзя обрабатывать сколько-нибудь значительные объемы данных? В том же F# списки можно использовать только для написания симпатичных примерчиков вроде

copy to clipboardподсветка кода

1. let rec insertions x = function  
2.     | []             -> [[x]]  
3.     | (y :: ys) as l -> (x::l)::(List.map (fun x -> y::x) (insertions x ys))  
4.   
5. let rec permutations = function  
6.     | []      -> [ [] ]  
7.     | x :: xs -> List.concat ( List.map (insertions x) (permutations xs) )  

но даже его, для реального использования необходимо переписывать через sequence. А sequence, в свою очередь, является простой оберткой на IEnumerable, для которого не определена определена операция Cons(head, tail), то есть в сопоставлении с образцом использовать нельзя, кроме как введением костылей вроде

copy to clipboardподсветка кода

1. let (|SeqEmpty|SeqCons|) (xs: 'a seq) = //'  
2.   if Seq.isEmpty xs then SeqEmpty  
3.   else SeqCons(Seq.head xs, Seq.skip 1 xs)  

которые безбожно тормозят, поскольку каждый Skip порождает новую цепочку вычислений, которую надо разворачивать с самого начала. То есть матчить sequence нельзя, а для повторного использования результатов вычислений его постоянно оборачивают в Seq.cache. А на все вопросы относительно такого поведения, так называемые гуру дают ответ, что надо просто использовать LazyList из FSharpPowerPack. Ленивый список ок, его можно матчить и семантически он аналогичен кешированному Seq, но для него не определены computation expression, хотя это совсем незначительный эстетический недостаток.

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

Так же, у меня сложилось мнение, что немерлисты односвязанному ииммутабельному списку предпочитают родные дотнетовские List[T] и oh shi~ Array[T] с соответствующими императивными паттернами, даже специальная конструкция для выхода из множества вложенных циклов есть. То есть ЧИСТОТА не в почете.

Есть какие-то разумные объяснения подобной ситуации? Почему они встраивают энергичные списки в язык, если ими физически невозможно пользоваться?


PS: Забыл сказать, что идет июньский конкурс по функциональному программированию. Мое текущее решение на Nemerle отрабатывает за 42 секунды на нетбуке. Хочу попробовать переписать код с использованием ассинхронных вычислений, надеюсь побыстрее будет. Может кто-то хочет показать класс, решив задачу еще быстрее?

Comments

[justy-tylor.livejournal.com]

Сейчас по приколу удалил умности из вчерашнего алгоритма - сменилось с 3m17s на 2m50s в тормозном интерпретаторе Python.
Переписывать на сях с паралеллизацией как-то западло - сумма времени написания кода превысит час, а это мой предел на "спец. олимпиады".

Про списки cons(head,tail) - а зачем это легаси тащить? http://vimeo.com/6624203 К ленивым тоже относится.

[stdray.livejournal.com]

>сумма времени написания кода превысит час, а это мой предел на "спец. олимпиады".

Ну мне интерсно поиграть с Nemerle, разобраться с его async'ами (http://habrahabr.ru/post/108184/).

>Про списки cons(head,tail) - а зачем это легаси тащить? http://vimeo.com/6624203 К ленивым тоже относится.

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