Функциональный язык с расширяемыми записями
А вот что у нас есть из функциональщины со статической типизацией, но чтобы типы записей не нужно было объявлять заранее вообще, но при этом они бы свободно участвовали в выводе типов?
Очень уж удалбывает при работе с БД и оперденями необходимость объявлять типы. Использовать кортежи неудобно - без имен не поймешь что где в кортеже из 20-30 полей.
Приходится использовать кложурь и мапы с keyword-ключами и следить за собственной головой при рефакторингах, чтобы не поломать все нахрен, т.к. проверок статических там вообще никаких нет.
В LINQ в C# мы можем сделать анонимный класс с именованными полями, но вроде не можем вернуть его из функции и использовать где-попало за пределами текущей области видимости.
В F# ад и содомия - записи нужно объявлять заранее, что дичайше огорчает при рефакторинге - приходится бегать между объявлением и тыщами мест создания записей.
В хаскеле записи вообще, похоже, срачеразжигающая тема и ни одно из расширений вроде не считается общепринятым.
PS: Язык должен быть с иммутабельностью, хотя бы как в clojure и со статической типизацией. Зачем вы жабаскрипт вспоминаете, если я явно написал, что clojure напрягает отсутствием статического анализа кода?
Очень уж удалбывает при работе с БД и оперденями необходимость объявлять типы. Использовать кортежи неудобно - без имен не поймешь что где в кортеже из 20-30 полей.
Приходится использовать кложурь и мапы с keyword-ключами и следить за собственной головой при рефакторингах, чтобы не поломать все нахрен, т.к. проверок статических там вообще никаких нет.
В LINQ в C# мы можем сделать анонимный класс с именованными полями, но вроде не можем вернуть его из функции и использовать где-попало за пределами текущей области видимости.
В F# ад и содомия - записи нужно объявлять заранее, что дичайше огорчает при рефакторинге - приходится бегать между объявлением и тыщами мест создания записей.
В хаскеле записи вообще, похоже, срачеразжигающая тема и ни одно из расширений вроде не считается общепринятым.
PS: Язык должен быть с иммутабельностью, хотя бы как в clojure и со статической типизацией. Зачем вы жабаскрипт вспоминаете, если я явно написал, что clojure напрягает отсутствием статического анализа кода?
no subject
А если по теме C# - есть dynamic жэ. Я даже видел ORM на этом.
no subject
no subject
no subject
no subject
no subject
Там же ад внутри и никакой статической типизации и иммутабельности.
no subject
no subject
no subject
no subject
http://roy.brianmckenna.org/
no subject
no subject
no subject
no subject
no subject
...он включает в себя полную реализации всего стека возможностей JavaScript, расширенных поддержкой статической типизации и обеспечивающий полную поддержку Node.js и MongoDB...
...данный фреймворк также может использоваться в качестве самостоятельного языка программирования: приложение, будучи написанным на Opa, будет автоматически проверено на качество его кода, после чего может быть автоматически сгенерировано аналогичное по функциональности Javascript-приложение....
no subject
Но генерить это руками - это печаль.
no subject
no subject
no subject
http://www.impredicative.com/ur/tutorial/tlc.html
no subject
no subject
Т.е. на старте запускаемся, коннектимся к БД, ищем описание таблицы, генерируем код, потом дергаем ручку, компилим и дальше всё чисто статически.
no subject
no subject
metaclass хочет динамически создать тип например так:
... select new { Upper = w.ToUpper(), Lower = w.ToLower() };
И потом везде по коду пользоваться как статическим - item.Upper;
Весь дотнет стек ему похоже не поможет.
no subject
no subject
Осталось вспомнить, почему я это не использую в связке с F# - что-то там было совсем уж дикое, то ли синтаксис от версии к версии менялся, то ли поддержка БД была совсем уж условная.
no subject
no subject
http://hackage.haskell.org/packages/archive/HList/0.2.3/doc/html/Data-HList-Record.html
Имена полей можно переиспользовать, а в типе функции от записей требуется только содержать необходимые поля. Вкупе с Constraint Kinds должно получиться хорошо.
no subject
no subject
no subject
По моему намного проще настругать обертку на кейс классах, аля
case class UserRecord(id: Long, name: String, login: String)
и дальше ее спокойно использовать при создании как
val x = UserRecord(10, "Теодор", "unabomber")
и использовании как:
println(x.name)
no subject
Или тебе не для БД, а "вообще"?
no subject
no subject
Можно сгенерить правильные туплы или record'ы под всю строчку такой-то таблицы.
Но бывают и SELECT'ы, задействующие не все столбцы таблицы, ну и это можно побороть.
А бывают ещё и всякие функции типа агрегатов. Итипатого.
no subject
Он не очень страшный, изучить недолго...
no subject
а он мне:
Статическая утиная типизация в действии. окамл.
no subject
no subject
gist.github.com/2964305
Также:
hackage.haskell.org/package/has
Пока нужно объявлять поля, но в новых ghc есть типы-строки, которые эту проблему устраняют.
no subject