http://www.joachim-breitner.de/blog/684-Constructing_a_list_in_a_monad_revisited — в догонку к #2806440. Один пошутил на тему того что можно хакнуть Nil через C-- и получить дешёвую вставку в конец списка. Другой забенчмаркал это и пришёл к выводу что это отличная идея. Теперь полагаю надо ждать Hack Hole Proposal в кафе. Не зря меня так напугал исходный пост.

http://twanvl.nl/blog/haskell/unsafe-sequence — Здесь неподалёку есть старое индейское кладбище. Если похоронить там кого-нибудь то он оживает. Но вы пожалуй лучше не делайте этого никогда.

http://tab.snarc.org/posts/haskell/2015-09-29-rust-with-haskell.html — Все мы знаем, что haskell — идеальный язык для любых задач и лишь недостаток библиотек не даёт использовать его в больших серьёзных проектах уровня национального поисковика. Но теперь ваши мольбы услышаны и решение есть: интероп с Rust! ТАДА!

> Сначала ты пишешь простую сумму типов для представления состояния мотора. Потом произведение этих состояний как суммарный статус моторов девайса. Затем ты понимаешь что тип состояния мотора это моноид с нулём в «со мной всё ок, но я ничего не делаю». Затем ты понимаешь что если тип произведение сделать полиморфным, то компилятор сможет вывести ему Foldable и можно будет узнать суммарный статус всех моторов библиотечной свёрткой. ЭТО ЖЕ ЛОГИЧНО! Затем ты выдыхаешь, время возвращается к привычному темпу и ты понимаешь что ты хочешь ещё этой травы.

Напомните мне комикс про двух лисперов занимавшихся магией в мире хаскеля и в конце концов по решению суда раздавленных чекалкой Хиндли-Милнера?

Каждый раз когда сажусь покурить дисциплину очень быстро охуеваю от вербозности и нечитаемости типов. И это говорит человек добровольно пишущий на haskell'е.

Есть у меня устройство, которое может находится в одном из нескольких конечных состояний. Для разных состояний устройства есть разные способы отправить его в другое состояние. В принципе можно описать все эти способы функциями над монадой State, а сами состояния изображать конструкторами алгебраического типа. Но тогда в рантайме придётся перепроверять а в правильном ли мы состоянии для вызова этой функции. Кроме того из самой функции будет не очевидно когда её можно вызывать. Можно закодировать состояния разными типами, а машину состояний суммой этих типов, а способы кодировать специальной монадой параметризованной типом состояния в котором можно её использовать. Но тогда нужен типобезопасный case, который позволяет при удачном сопоставление выполнять вычисления только внутри нужной монады. Кроме того типов станет ещё больше. Я недавно столкнулся с тем, что у меня есть типы параметризованные восьмью переменными и нужно ещё!

У меня ни одного пакета на хэкедже. Никак не решу плохо это или хорошо.

Ты хаскелист, дрочишь на монады, аппликативные функторы и ленивые вычисления? Тебе на страницу 6 http://www.ittc.ku.edu/csdl/fpg/files/Gill-15-RemoteMonad.pdf

ndtimofeev> Хм… У меня есть устройство которое со стороны программы моделируется набором довольно независимых свойств. Интересно, смогу я каким-нибудь quickcheck'ом нагенерить случайных программ для устройства чтобы ПЫЩ-ПЫЩ ТЕСТЫ. lexszero> через год ты quickcheck'ом будешь генерить соединения для скрининга?

Писал сырой stg. Стал let … in-блядью. :( Что теперь делать?