IT-redneck

Вспомнил один срач на тему однопроходных компиляторов, где Steve Yegge критиковал Clojure за то, что в ней объявления видны не во всем модуле, а только ниже объявления. (Ну, за исключением declare которые что-то вроде forward-объявлений).
Сижу приделываю новую фичу к кодогенератору на F# - и таки внезапно оказывается, что это не только в Clojure, но так же и F#, и, что самое печальное, - в долбаном SQL, который я генерирую.
Сижу вот, сортирую объекты из которых генерируется SQL по зависимостям.

А как с этим дела обстоят в Scala?
Я тут подумываю, что надо бы провести сравнение F# и Scala на моих задачах, все равно уже полная работа JVM и жаб, так может, выводилка типов в Scala для меня окажется более приемлемой, чем дикий ад в F# (теперь я понимаю, почему его thesz критикует). Ну и макросы в скале xeno_by прикрутил вроде уже.
Хотя единственное, что мне приходит в голову на тему приличного использования макросов - это при их выполнении долбится в БД или модель этой БД и генерировать код.

Элементарно.
Экспортируем из опердени датасет с 381 записью по 40 полей в каждой в формат исходника F# и пытаемся это компилировать. Каких-то несчастных 10 тыс строк и 660 килобайт кода. Компилятор сдыхает с переполнением стека. Так же как и хаскель когда-то в такой же ситуации.
Придется все-таки для таких целей написать адекватную сериализацию, чтобы данные лежали не в исходнике, а отдельно, а исходник содержал только метаданные и код чтения.

Вообще, изначальная идея такова - часто есть необходимость произвести некое нетривиальное вуду над отчетом для проверки, и мне кажется, что экспорт отчета в виде исходника, а затем загрузка этого исходника в интерактивную консоль хаскеля или F# - это самый простой способ надругаться над данными отчета функциональщиной.
Например, сегодня была надобность из метаданных SQL запроса генерировать более другой запрос, чтобы эти самые пресловутые 40 полей не повторять 10 раз вручную.

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

( Read more... )

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

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

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

Ради теста обновил F# с 1.9.7.8 до 2.0.0.0. Сломалось:
1) fslex, fsyacc ставятся отдельно с FSharp PowerPack, в основную инсталляцию не входят
2) Warning насчет имени модуля в начале файла стал полноценной ошибкой - пришлось поправить исходники парсера и опцию --module для fsyacc чтобы это имя модуля появилось в сгенерированных файлах.
3) Самое неприятное для меня изменение - теперь optional parameters могут быть только в конце сигнатуры метода, а у меня было штук 5 конструкторов с опциональными параметрами в начале - это AST для генерируемого кода и там по логике идет что-то вроде такого:
([опциональные атрибуты] [опциональный модификатор видимости] тип имя [опциональный код инициализации])
В общем, это обходится досточно просто - делаем вместо одного конструктора несколько - один со всеми параметрами, и остальные - с наиболее часто встречающимися вариациями вызовов.

ChangeLog для F# 2.0 я найти не в состоянии, может меня конечно гугл лично ненавидит в этом плане, не знаю.
И вообще, F#, конечно, язык весьма удобный, но ставить его в продакшен за пределы личного использования я как-то опасаюсь - очень уж разрозненные сведения по нему в интернетах и выглядит это все, как будто он живет усилиями Дона Сайма, проталкивающего его всюду.

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

Спор про F# (там рекаптча если шо)

Товарищ прицепился к тому, что в F# нельзя написать функцию, которая бы по индексу поля в кортеже возвращала бы значение поля.

Т.е. вообще-то ее написать можно, через Reflection, но 1) это все только благодаря дотнету, но никак не системе типов; 2) это противоречит духу статической типизации и является способом стрелять себе в ногу.

Никак не могу человеку объяснить разницу между статической типизацией и натягиванием совы на глобус реализацией динамической типизации поверх языка со статической, чем занимаются 90% либ доступа к БД (все эти ADO.NET, ODBC, JDBC, BDE и прочая).

Смотрю .NET Reflector на внутренности программы на F# и всячески торчу.
50 строк на F# разворачивается в четыре автосгенеренных класса-замыкания, автоматически управляющих десятком объектов для доступа к базе данных и все это в итоге представляет собой функцию "коннект к Firebird -> хитрозаколдованная структура с данными".

А я еще собираюсь и сам код на F# сгенерить из результатов парсинга запросов в БД, чтобы вообще руками ничего не писать, кроме SQL запросов. Т.е. "чтобы было все и мне за это ничего не было".

Т.е. идея примерно такая:
1)есть структура реляционной БД - мне в ее категориях проще проектировать и думать.
2)есть запросы к ней и связи между ними - которые мне тоже проще придумать, чем делать маппинги в ORM или писать запросы на LINQToSQL, который вообще не факт что поддерживается для Firebird.

Я описываю запросы на SQL, кодогенератором автоматически конвертирую их в функции F# вида ("коннект к БД" -> "параметр запроса 1" -> "параметр запроса 2" -> ... -> "ленивая последовательность записей с результатами").
Затем полученные функции я собираю в законченную структуру, описывая связи между ними уже на F# и получаю на выходе что-то вроде "Запись, поля которой представляют собой ленивые последовательности с результами запросов, причем внутри эти результатов могут быть такие же поля - ленивые последовательности с результатами вложенных запросов".

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