А вот в Хаскеле partial application убогий:

f x y z = x + y * z;

а хочешь частично применить только x и z — и болт: изгаляйся. f1 x z y = f x y z; q = f 10 3; q 2

В kdb+ веселуха,

f:{[x;y;z]x+y*z} — определение ф-ии
var1:f[10;;3] — частичное применение, параметры разделяются ";".
(Ну а если последние параметры надо оставить висяком, то и точки с запятыми тоже не нужны).
var1[1] — дает 13
var1[2] — дает 16

короче, пока я не узнал, все ломал голову, где же функция flip.

А вот на тебе, на лопате, не подавись!

1. приложение выдает 1к rps и тормозит, как не должно
2. добавляешь в контейнер GHCRTS=-N4
3. приложение выдает 4.5к rps

оптимизация like a boss, а в го бы пришлось вручную память менеджерить.

Ах вот оказывается для чего они запилили 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