IT-redneck

Firebird и лямбда-функции, часть 3:
Я таки спросил про функциональное программирование, и к чему это привело:


>> т.е. если оно не исчезнет через год-два-три, возможно посмотрю пристальнее.
> ну в высоконагруженных сильнопараллельных программах оно существует уже не год-три, Erlang и написанные под его влиянием
> библиотеки.
Я не собираюсь продолжать эту беседу ибо она была спровоцированна с единственной целью - поржать в ЖЖ над частично процитированным и оторванным от контекста моим частным мнением. Выставляя косным идиотом не только меня (на это мне наплевать), но и Firebird вместе со всем его сообществом.


Короче, не выходит у меня дискуссия на тему "как скрестить базы данных и функциональное программирование". Все уперлось опять в то, что я не пресекаю критику Firebird и его сообщества у себя в ЖЖ. Есть какой-то элемент сектанства в сообществе, мешающий объективно и без эмоций воспринимать критику. Ладно бы еще я призывал всех на другие СУБД переходить - понятно, конкуренция типа. Да и то это без эмоций разруливать удобнее.

Домудрился с вложенными ленивыми секвенсами вперемежку с обращениями к БД до такой степени, что сломал компилятор F#, похоже. Во всяком случае, он у меня теперь умудряется сделать Dispose команде доступа к БД до того как начнет генерить последовательность из нее. Причем, что удивительно - не всегда, а только при определенном паттерне обращения к другим командам.

( Read more... )

Однозначно, что ленивость+внешние ресурсы это не совсем то, что следует делать, да и отладке это не подлежит в принципе, ибо монады. Но как превратить это дело в fold-like алгоритм, хрен его знает, да еще с учетом того, что там внутри не просто итератор по плоским записям, а внутри этих записей еще вложенные итераторы, а из них ссылки на элементы из других итераторов, в общем, ад тот еще.
Вот еще смех будет, если это не в F# проблема, а в ADO.NET провайдере Firebird.

PS: Судя по всему, все хорошо и пень все таки я - таки ленивые вложенные итераторы можно использовать только вложенно, а не так как я - сначала пройтись по внешнему, найти нужную запись, а потом из нее читать вложенные. Адекватный вариант - сделать их неленивыми. Обычно в этом помогает Seq.cache, но тут он, похоже, тоже вызывается в неподходящий момент.

PPS: Ухуху, и решение в этом случае действительно, как и советуют гуру ленивости - перевернуть все в fold-like алгоритм, передав две функции - одну для fold внешнего итератора и одну для fold внутреннего (и вроде в общем случае, еще две - одну которая будет из внешнего итератора и состояния делать начальное состояние для fold внутреннего, и вторая будет комбинировать результат от fold внутреннего итератора и состояние внешнего).
Это получается, что для fold в случае вложенных итераторов количество передаваемых параметров-функций прилично возрастает: по одной функции на каждый итератор в иерархии и +2 на каждый случай вложенного итератора, причем у самих этих функций количество передаваемых в них параметров тоже особой радости не доставляет.
Зато соответствующим набором таких функций, судя по всему, можно вычислить произвольную функцию от базы данных, представленной в виде набора разнообразно вложенных итераторов :)