я тоже нашел бимап:)

Благодарю.

не успел:)

блин мне опять сервант мозг ест

иногда он сложный блин

Когда знаешь, что такое существет, но вспомнить не можешь :(

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

finally не прикрывает исключения

Так, а чем их можно прибить?

catch сделайть

честно ловить try?

finally action finallier = (action `catch` (\(SomeException e) -> finalizer >> throw e) >> finallier

try/catch

можно взять safe-exceptions/exceptions-safe

оно часто работает

так вот сервант

я сделал Streaming ответы, если они выдают стрим в каком-нить IO то все круто

но вот теперь у меня стрим в чем-нить более сложном, например ResourceT IO или даже ResourceT (Reader Db IO) и чего делать непонятно

контекст должен жить дольше, чем сервант делает ответ

Тоже приходится через сервантные приколы продираться. К счастью, есть колоеги, умеющие в магию на типах, можно у них код покрасть.

т.е. его надо в HasServer отдавать

магия на типах это просто

не просто когда там внутри их бесконечные HasServer со 100500 недокументированых параметров и сервантовых врапперов в internals

хорошо, конечно когда авторы серванта в чятике есть

но все равно иногда тяжело

Ну у меня проще, пока никакой магии я переплёвываюсь между потоками через chan если кто умер, то сообщаю через finally по тем же чан :)

@qnikst в рабочем чатике?

(я не могу угадывать, но возможно async пакет может помочь)

Kirill да

это кстати и минус

магия на типах это просто

Это то, за что нужно бить по рукам. Если сервант еще ничего, то Opaleye уже слишком. А коллега к тому же наворотил свои рекорды сбоку. Очень высокая accidental complexity.

А кто у вас из авторов?

Junial Arni

или как там фамилиё

Julian

А, даже так, кул

Альп был, но он ушёл и свою фирму сделал давно ещё

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

А как зовётся?

Фирма альпа?

Не в паблике?

не знаю

я с ним особо не общался

Да, кстати. Можете накидать хорошие материалы по type families?

@qnikst a на сайте у него WT

хм.. ну может быть

Александр я в основном по документации в trac разбирался и с кучей игр со всякими регионами и т.п.

про опалай, кстати, наверное я согласен

но может мне было лень разбираться

Дело в том что получаешь путем усложнения. Если получаешь много всгео и нахаляву, то почему бы и нет.

Я вот сторонник макбрайдовской философии

пусть типы пишут программы

Дело в том что получаешь путем усложнения. Если получаешь много всгео и нахаляву, то почему бы и нет.

Получаешь высокий порог входа. Если хочется и дальше новичков от Хаскелля отпугивать, - то пойдет.

мне все равно что думает гипотетический новичок про мою кодобазу

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

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

давайте все на го писать тогда

давайте все на го писать тогда

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

го это не абсурд, это реалии индустрии

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

Вы говорите так, будто “продвинутый разработчик” – стигма какая-то.

Вы говорите так, будто “продвинутый разработчик” – стигма какая-то.

масонский кружок

го это не абсурд, это реалии индустрии

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

Если предметная область объективно сложна, то и её представление в типах тоже сложно, как бы оно просто не выглядело на бейсиках.

Если предметная область объективно сложна, то и её представление в типах тоже сложно, как бы оно просто не выглядело на бейсиках.

Предположу, что просто не опдобраны нормальные абстракции... оно часто так бывает. Сначала сложное, а потом выразишь через какую нибудь новую штуку и станет просто и понятно...

Есть essential и accidental complexity. Против других дизайнерских решений типы проигрывают по второй шкале.

А вообще, есть вроде минимальная сложность представления. И с этой гадостью ничего не сделаешь :(

Но тут опять же нужно честно доказывать теорему, что проще чем Х явленияе Y записать не получится и хоть ты тресни :(

именно. https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/#why-bother-to-make-these-complicated-types

Но магия на типах привносит свою accidental complexity, и она больше, чем у других решений (free DSL, например)

Причем тут free?

Если нужны статические проверки, то нужны типы.

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

(ну во втором случае еще TH и прочие разновидности дженериков иногда помогают, но зависит от случая)

>Хотите чтобы компилятор больше кода за вас писал - типы. Шаблоны и кодогенерация?

в шаблонах типы

А вот как заставить типами писать код типами, честно не знаю.

Разве что классами типов обобощать...

типы пишут термы

Но это не совсем написание кода :)

когда это возможно