← All posts tagged Haskell

Ах вот оказывается для чего они запилили GADT: "to construct a safe list type for which the equivalent of head [] fails to typecheck and thus does not give the usual runtime error: *** Exception: Prelude.head: empty list". Хорошо надрачивают! Уже думаю пора пойти посмотреть что полезного можно сделать при помощи линеаризованных типов. Понятно что след за утечками памяти в прошлое уйдет и сборщик мусора, но вот можно ли будет так с ними жить...

Наконец нормальное разъяснение контравариантных функторов typeclasses.com . Главное тут написано где надо, а главное где не надо искать этот паттерн. Как только осознаешь что речь идет про морфизмы по сути своей сводящимися к (-> z) сразу перестаешь ломать голову как же блин построить обратную функцию, а начинаешь уже думать в контексте функциональной композиции. Нет путаницы в примерах когда не понятно кто из этих конкретных типов в предикате на самом деле свободных параметр или что в каждом контексте значит тип a

Поскольку голове несколько полегчало, то в планах на вечер вешить хаскелевую задачку на доказательство леммы Yoneda. codewars.com Чтоб показать изоморвизм надо среди прочего, судя по необходимому типу, определить контравариантный функтор (a -> b) -> f b -> f a И если на диаграмке со стрелочками еще можно сообразить почему он должен существовать, то как реализовать его в реальности да еще и параметрически полиморфным образом мыслей пока нет.

А я правильно понимаю что даже если граф ациклический, то все равно надо забить на алгебраические структуры данных? При модификации стоит просто идентифицировать ноду по уникальной метке/индексу? В моем случае структура графа не меняется, но меняется содержимое ноды после каждого суска. Как лаконичнее в этом случае описать структуру данных?

Смотрю перед сном лекции по теории категорий. Лектор просто офигенен. Благодаря ему моего внимания хватает на академический час и при этом не теряю мысль через 5 минут, а лишь изредко перематываю назад непонятные места. При этом это не доклады в стиле "смотрите дети, это функтор". Но на втором академическом часе я начинаю клевать носом и наступает крепкий и здоровый сон. youtube.com

А как я могу поименовать List по имени типкласса чтоб использовать его в констрейнах? Например типа такого: instance List a => Foo a where ... Использовать [] справа единственный вариант? Хочу указать слева аналогично Num a =>

Хочу в деталях понять как работает система типов, пока нет единой модели в голове что конкретно делает конкретный нетривиальный систаксис при программировании на типах. Если ли вменяемый гид по реализации System F в Хаскелл, который можно порекомендовать? Я наверно не убоюсь матлогики в ограниченных объемах, но хотелось бы не сколько про теоретическое лямбда счисление, сколько про конкретную реализацию в Хаскелл в его терминах.

В продолжение #2877060 youtube.com Короче нормально все в Хаскеле. По другому, но чуть ли не навороченнее. Там есть тупой промежуточный язык с типизованными лямбдами в который после типчекера транслируются все хаскелевые абстрактные навороты. А уже потом когда надоест гонять оптимизатор по кругу можно преобразовать в C, либо еще в какую фигню. stackoverflow.com

Знаю что есть вполне себе определения парсера и типчекера Haskell в терминах Haskell. Но вот чтоб полностью и рантайм и компилятор определить — вроде бы нет такого. Идея в том что бы не писать ни строчки С-шного кода руками, а генерить его заведомо корректным под конкретную архитектуру. Спрашивается WTF, что помешало ребятам сделать так с самого начала?

Считаю что данная конструкция прекрасна в своей лаконичности и "простоте" =)
fmap (>>= f) aНадо видеть каким чеширским котом медленно расплывалась моя лыба когда я впервые увидел это