Типы и типы

[metaclass]

Очевидно ли, почему flatten и (partial apply concat) в Clojure могут выдать разные результаты? После хаскеля кложурный flatten, работающий на все уровни "вглубь", выглядит непривычно.

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

Comments

[(Anonymous)]

а вот вопрос можно?

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

как отражать в статических типах данных эти изменения?

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

так вот - можно ли как-то получить удовольствие со статическими типами?
(например в веб-фреймворках можно встретить некий вспомогательный механизм "миграции" для типов данных в таблицах.
и по этим миграциям изредка видно, что куда менялось, и даже можно бывает что-то откатить в какую-нибудь сторону.)

[metaclass.livejournal.com]

Вот в этом основная проблема и оказалась.
Требуется вывод типов не "во время компиляции", а "при запуске программы" или "при проверке не изменилась ли схема внешнего источника данных".

Миграция опять же - в обычных языках или нет, или закат солнца вручную, нормально в динамических, а в статических вообще до этого не дошло, потому что на них факториалы считают, или же типы входных данных никогда не меняются.

[thesz.livejournal.com]

Некоторые Хаскельные библиотеки связи с БД поддерживают миграцию.

[metaclass.livejournal.com]

Лучше бы их вообще не было :)
Большая часть ORM и тому подобного на любых языках - тяжкий невыносимый ад.

[(Anonymous)]

может я ща фигню сморожу, но просто пока в треде много хаскелистов, можно попробовать:

а имеет смысл как-нибудь привязать к каждому типу данных номер коммита или текущую дату, а потом делать линк с коротких обычных имён типов данных на самые последние по времени?

и описать миграции (в какую получится сторону в каждом случае).

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

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

может правда это нихрена хорошего и не даёт, я хз (

[victor bolshakov (from livejournal.com)]

А чем существенно компиляция от запуска отличается? Ну кроме того как оно сейчас реализованно...

[metaclass.livejournal.com]

В кложури вообще ничем.

[(Anonymous)]

а ещё грят у злодеев из эрланга есть демоническая перезагрузка кода (нахаляву), и вообще они якобы с самого начала стараются строить программу так, чтобы она после этой перезагрузки не только падала, но и поднималась обратно ((
c:Conner, whysmai

[theiced.livejournal.com]

в кложуре можно вообще сванк в прогу всунуть и говнокодить прям в работающем продакшне.

[(Anonymous)]

тебе смешно, а как в руби такую хрень замутить.. (
тока не надо писать, что это не нужно.
там вон у народа была какая-то zeromq, но хз как это поможет (

[blackyblack.livejournal.com]

Есть такая. Штука действительно демоническая, но в целом понятная. Там просто супер-цикл, в котором постоянно обрабатываются сообщения. Можно залить код, положить его рядом, а потом послать сообщение, в котором выполнение перенаправится на новый код. Такую штуку можно сделать и в обычных языках, но за счёт ориентированности на обработку сообщений и функциональный стиль, получается просто и из коробки такой трюк.

[kurilka.livejournal.com]

Не надо там сообщений, просто следующий вызов module:function(...) после обновления приведёт к выполнению кода уже нового модуля (за минусом подробностей типа gen_server:conde_change/3 и т.п.)

[blackyblack.livejournal.com]

Не верю. Насколько я помню, в книжке явно слали сообщение для замены кода.

[kurilka.livejournal.com]

Ну против верований возражения придумывать нет желания.
Реально же достаточно в консоли l(module) сделать, но по-нормальному, конечно, стоит release_handler использовать, а в принципе в документации все описано - http://www.erlang.org/doc/man/code.html#id101126

[blackyblack.livejournal.com]

code:load_file я делал. Но, насколько я помню, если в модуле рекурсивный вызов без обработки сообщений, то обновить такую функцию нельзя.

[kurilka.livejournal.com]

code:load_file - это не сообщение, касательно обработки сообщений - это не так, хотя с практической т.зр. иметь рекурсивную функцию в процессе (модуле), которая не читает сообщения, довольно бессмысленно. Касательно "нельзя" есть лишь ограничение на то, что вызов должен иметь вид module:function, т.е. вызов без указания модуля обращается "в ту же версию".