Ну я уже много раз говорил, что считаю mtl как раз boiler plate. Люди почему-то смотрят на FM и видят бойлерплейт в интерпретаторах, когда их один раз написал и забыл. А вот boilerplate в бизнес-логике, который приходит с системами эффектов и FT, они не видят

(Ну и еще там была проблема квадратичного количества инстансов где-то для mtl)

Александр Гранин вышел из чата

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

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

Или я тут не прав и есть какое-то красивое и удобное решение этой проблемы и с фри монадами?

Или подразумевается, что фри монады мы используем строго для эффектов внутри одного обособленного приложения, а в библиотеках обходимся без них?

> когда надо совместить в одном месте два разных эффекта из разных библиотек или модулей.

Это системы эффектов и пытаются делать. Это проблема именно систем эффектов, просто некоторые из них используют фри монады для описания эффектов. Но сами фри монады тут ни при чем.

"Совмещать эффекты" - это какой-то вообще неправильный путь. Всю жизнь жили без совмещения эффектов в мейнстриме, и было нормально. Потому что были не эффекты, а подсистемы, и их не надо было совмещать в районе бизнес-логики, а нужно было взять/сделать фреймворк с готовыми и его использовать. Информация о том, что для какой-то функции совместили два эффекта, а для другой функции не совместили - на практике является бесполезной и misfeature. Она только мешается рефакторить. В реальности все функции бизнес логики так или иначе сталкиваются с необходимостью использовать все подсистемы, и там вообще нет времени для балансирования, каким функциям можно, а каким нельзя

Например, мои фри монадические фреймворки не требуют "совмещать эффекты", а уже предоставляют нужные подсистемы из коробки. Это то, что в мейнстриме давно делают, давно испробовано и удобно.

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

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

Чот ищу-ищу, а исходного сообщения Doge нигде найти не могу ни в одном из чатов где он, как я знаю, обитает

Значит, есть еще один чат? @DogeShibu

А, точно, еще в шарповую флудилку не заглядывал

Что можно почитать про таглес файнел и фри монады людЯм кто только с монадами, моноидами и полугруппами разобрался?
"Хотелось бы в общих чертах понять, о чем интурист говорит"(С) И.В.Бунша

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

А вот фреймворк по умолчанию будет сделан конкурентно, и не будет зоопарка эффектов в коде.

Ну ясно ж чо! Правильные хаскеллисты всегда к Олегу отправляют! Киселеву.

А раз я неправильный хаскеллист, то я не буду. Все что нужно, я о фри монадах рассказал в своих материалах. К сожалению, равного по полноте и консистентности источника про FT не существует (в Хаскеле, по крайней мере)

Но всегда можно почитать флудилку по F#, там за FT и FM как надо заяснят

А правильных ссылок на свои материалы нет?

Да есть, сейчас запощу

Я после скала понва снова пить начал... Кефир... Прям боюсь во Фшарпнутую флудилку идти, как бы на ряженку не потянуло😺

про тф олег же много писал