Плохой совет, учитывая, сколько всего можно сделать с IO.
Именно поэтому из IO и надо по возможности уходить
IC
Alexander
Именно поэтому из IO и надо по возможности уходить
Вычислительную логику нужно выносить из IO. Можно также кодировать эффекты чистым eDSL и потом его исполнять.
Но поскольку функции IO - это еще и первоклассный объект, то ничего плохого нет в том, чтобы их генерить в чистом коде, чтобы потом выполнить. А еще есть всякие функции по работе с монадой (mapM, replicateM, etc.) Совет от @Masteroid скорее вреден, чем полезен. В достаточно большой программе IO всяко будет не только в функции main.
Alexander
Правильный совет звучал бы как-то так:
По возможности выносить вычисления в чистые функции, отделять эффекты.
IC
Вычислительную логику нужно выносить из IO. Можно также кодировать эффекты чистым eDSL и потом его исполнять.
Но поскольку функции IO - это еще и первоклассный объект, то ничего плохого нет в том, чтобы их генерить в чистом коде, чтобы потом выполнить. А еще есть всякие функции по работе с монадой (mapM, replicateM, etc.) Совет от @Masteroid скорее вреден, чем полезен. В достаточно большой программе IO всяко будет не только в функции main.
Вне main скорее всего будет трансформер или ещё какая нашлёпка.
IC
Только если это не что-то скриптообразное. И то там черепахи до самого низа...
Ilya
Вычислительную логику нужно выносить из IO. Можно также кодировать эффекты чистым eDSL и потом его исполнять.
Но поскольку функции IO - это еще и первоклассный объект, то ничего плохого нет в том, чтобы их генерить в чистом коде, чтобы потом выполнить. А еще есть всякие функции по работе с монадой (mapM, replicateM, etc.) Совет от @Masteroid скорее вреден, чем полезен. В достаточно большой программе IO всяко будет не только в функции main.
>В достаточно большой программе IO всяко будет не только в функции main.
да это понятно, только ты посмотри, на какой код я отвечал. Человек пришёл из питона, и пишет как в питоне, с функциями String -> String -> IO. Я же сказал - "старайся". Понятно, что это не всегда возможно. Но в его случае не только возможно, но и необходимо.
Alexander
Вне main скорее всего будет трансформер или ещё какая нашлёпка.
Вне main может быть много чего. Даже IO, завернутое в чистый eDSL, которое потом должно когда-нибудь исполниться
Vladimir
К сожалению, иногда вынесение из IO стоит слишком дорого.
Alexander
@Masteroid Не вижу такой уж необходимости. Экспериментальный код, захотелось человеку комбинатор сделать, который работает в IO. Стиль по таким кусочкам отслеживать не совсем корректно
IC
Правильный совет звучал бы как-то так:
По возможности выносить вычисления в чистые функции, отделять эффекты.
Вот это и должно было быть в том первом ответе, а не "плохой совет".
Vladimir
Ленивый логгинг через monadwriter я так и не осилил, утекал он в память целиком. Проще оказалось в монаду прям io запихнуть.
Alexander
Ленивый логгинг через monadwriter я так и не осилил, утекал он в память целиком. Проще оказалось в монаду прям io запихнуть.
Writer это монада для созлания thunk leak
Vladimir
Да, узнал это трудным путём.
Vladimir
Пытаясь отделить IO как раз.
Alexander
на самом деле написать writer через CPS или строгий стейт можно
A64m
тем временем желающих читать пропозал про лин.типы так и не нашлось, так что секретарь рулевого комитета объявил о поиске желающего его прочесть повторно
Alexander
у меня есть теория, что фримонады стали популярными от желания использовать IO только в мейн
IC
Линивые типы..
Drunk
Alexander
у меня есть теория, что фримонады стали популярными от желания использовать IO только в мейн
Фри монады стали популярными, потому что позволяют делать Inversion of Control в чисто функциональном стиле. Сочетаются преимущества eDSL, безопасности, компонуемости, выразительности, при этом синтаксис остается кристально прозрачным.
Alexander
Напротив, ReaderT паттерн - это IoC в императивном стиле. Работает, но имеет те же самые проблемы.
Alexander
mtl - стиль тоже из серии "императивный IoC"
A64m
короче говоря, появились потому, что в хаскеле модулей не было
Alexander
Не знаю.
Alexander
final tagless это императивщина, так и запишем
Aleksei (astynax)
императивщина, это процедурщина!
Aleksei (astynax)
(или наоборот)
Alexander
Попробую прояснить. Императивный IoC, - это такой, для которого нечистый (IO) рантайм подменяется на время действия клиентской части. То есть, клиентские сценарии написаны в IO, и действуют непосредственно в нем. Иными словами, сценарии не отделены от IO-рантайма ничем, кроме, быть может, стека из других монад.
Aleksei (astynax)
в MTL стеке не обязан быть IO внизу
Aliester
как щитаете
Aliester
существует 10х девелопер?
A64m
но IO же абстрактный
если он имплементирован как АСТ, которое интерпретируется - это уже будет неимперативный IoC?
Alexander
Думаю, нет
Alexander
Думаю, существуют 10x нубы ;)
Aleksei (astynax)
0.1x developers
Alexander
но IO же абстрактный
если он имплементирован как АСТ, которое интерпретируется - это уже будет неимперативный IoC?
Это философский вопрос. Разграничение можно провести по возможности отлавливать эксцепшны
Aleksei (astynax)
Есть мнение, что 1x developer настолько же мифический, как и любой другой kx developer
Alexander
в MTL стеке не обязан быть IO внизу
mtl стеке внизу не обязан быть IO, возможно имели вы ввиду
Aleksei (astynax)
да, слов порядок вышел хороший не слишком
кана
final tagless это императивщина, так и запишем
ну так-то зига возможно бы сказал, что final tagless - терминальный интерпретатор в категории коалгебр, то есть ооп. Ну и в принципе был бы прав по моим суждениям
Aleksei (astynax)
Вы упороты :)
Aleksei (astynax)
И коупороты друг другу :P
Alexander
блин уменя дилема
Alexander
поидее нужно сделать типизированное GADT, но это так лень
Alexander
А является ли ООП с необходимостью императивщиной?
Alexander
и усложнит часть кода, с другой стороны 100500 случаев рассматривать не надо
Aliester
стрелочка от кого к кому?
Aleksei (astynax)
"Оголтело-отбитая парадигма"
Крылатый
Операционное отделение психиатрии.
Крылатый
Или особое отделение психиатрии.
Alexander
Очень Относительное Понятие
A64m
ООП == мутабельные ссылки
Vladislav
IORef это ООП теперь?
Aleksei (astynax)
OOPRef
Aleksei (astynax)
IOOP
Ilya
ООП это использование & вместо $
Aleksei (astynax)
А такая аббревиатура даже есть. Но во что раскрывается, я забыл...
Vladislav
Я бы сказал, что в первом приближении ООП это когда есть объекты, то есть группы методов, манипулирющих скрытым (инкапсулированным) состоянием. Типа
data Object =
Obj { doX :: IO (), doY :: A -> IO () }
где doX и doY оперируют общим IORef
Vladislav
И иногда так делать очень даже удобно, так что особо гнать на ООП я бы не стал
Vladislav
Но как фундамент для языка это бесполезно, конечно, т.к. объектами далеко не каждую сущность полезно представить
Aleksei (astynax)
Как всегда "технология ок, но люди - тупые"
Евгений
Всю жизнь думал, что ООП это структурная подтипизация
A64m
> Как всегда "технология ок
так никогда не бывает
Aleksei (astynax)
Технологии тоже плохие?
A64m
в одном языке, проще говоря
Ilya
Интересно, а в чате какого-нибудь C++ ведутся такие же упоротые разговоры о ФП? 🤔
Типа
- ФП это std::transform
- Нет, ФП это attribute _((pure))
- Нет же лол, ФП это [](auto a, auto b) {return a*b;};