Но внутре-то у ней неонка^W коллбэки!

Нет

f . g - тут f, это callback чтоли?

"Колбэки, это убогая беззаконная реализация монады", а не "монады, это такие коллбэки"

ого

Именем закона, прекратите свои реализации и сдавайтесь!

но законы монад едины

"Вы нарушили закон identity и приговариваетесь к пожизненному программированию на PHP!"

Я имел ввиду, что второй-то параметр (>>=) - коллбэк. А монада суть паттерн для последовательности вычислений.

На COBOL

Да никакой это не колбек!

... а "продолжение"

Это континюэйшн

я вообще нем понял тезиса про колбэк, откуда это вообще

"коллбэки", это просто ещё одна плохая аналогия. Как "буррито" и "контейнеры"

не могу понять интуицию, которая за этим стоит

ну ок

"коллбэки", это просто ещё одна плохая аналогия. Как "буррито" и "контейнеры"

тогда нахер не просто колбэки, а любые "монад туториалы" с аналогиями

буррито лол

Кажется, что кто-то просто наелся обработки асинхронности в JS и теперь любую передачу функции в параметре считает "коллбэком" :)

Ну типа запустили операцию getLine и сказали мол, что когда она выполнится, нужно выполнить функцию после бинда

тогда нахер не просто колбэки, а любые "монад туториалы" с аналогиями

this!

Как бы колбеки так неплохо накладываются разве что на io

Тру

Ну типа запустили операцию getLine и сказали мол, что когда она выполнится, нужно выполнить функцию после бинда

нет никакого "когда она выполнится". Она сразу выполнится

монада это шаверма. если вы хоть раз ели шаверму на районе, то знаете что такое монада

просто IO в хаскеле, это не "выполнение", это конструирование значения, которое "поймет" только main

Оттуда, что до монад было примерно так: data IO a = PutStrLn String (() -> IO a) (Error -> IO a) | GetLine (String -> IO a) (Error -> IO a) ... А монады явились способом организовать этот беспредел

Таки нет. За счет ленивости нихера там не выполняется сразу. Иначе нельзя было делать бы даже простой if внутри

Это не беспредел :) Это преждевременная free monad :)

Какой мультиплеер пошёл, прям deathmatch в чате

Оттуда, что до монад было примерно так: data IO a = PutStrLn String (() -> IO a) (Error -> IO a) | GetLine (String -> IO a) (Error -> IO a) ... А монады явились способом организовать этот беспредел

Вот это все намного понятнее

а на каком уровне работает магия IO? что если у меня кастомный prelude и никаких инстансов монады я не определял?

Это мне нравится

а на каком уровне работает магия IO? что если у меня кастомный prelude и никаких инстансов монады я не определял?

нету магии

IO, кстати, не требудет монад

Тогда у тебя нет и типа данных IO. И ввода-вывода, соответственно

GHC.Prim

нету магии

ну как нет, ты хочешь сказать IO целиком выражен средствами хаскелла?

монада реализована для IO только для того, чтобы поиметь do и композицию

IO, кстати, не требудет монад

так вот вопрос чего он требует

я не понимаю, на каком уровне он определен

IO находится за пределами хаскеля. Это конечный продукт, который производит хаскелева программа

Программа на хаскеле вообще ничего не делает с вводом-выводом

Она просто конструирует "программу на другом языке", которую выполнит интерпретатор встроенный в рантайм - вот он то и делает IO и вообще весь с эффектами и грязью

То есть единственное место, где можно делать эффекты - IO?

Эффекты, "повлияющие на внешний мир" - да

видимо, есть просто "эффекты" в широком смысле

Эффекты, которые не выйдут за пределы программы - запросто. State тот же

Ну так разве у стейта есть эффект? Он же просто возвращает новый "объект", следовательно иммутабелен, следовательно откуда там эффекты?

С точки зрения кода, который назодится в State, происходит явная "мутация состояния"

Суть State в разделении работы по поддержке сквозного состояния и кода, это состояние использующего

Абстракция, короче

Так то всегда можно пачку аргументов протаскивать через все вызовы и писать без State и Reader, но это будет "low level"

State же позволяет сказать "вот мы имеет настоящую мутацию, можем инкрементить счётчик в цикле, всё как у императивщиков" в выделенном участке кода, но при этом за пределами stayteful блока оставаться в рамках чистого языка, т.е. иметь композицию, ссылочную целостность, вот это всё

IO находится за пределами хаскеля. Это конечный продукт, который производит хаскелева программа

Это только одна точка зрения, а вовсе абсолютная истина. Чем представления об IO как об инкапсуляции линейности RealWorld'а хуже?

Всё-таки хаскель это не агда, чтобы смотреть на него как на траслятор

Можно запросто откатиться к IO в виде ADT ничего принципиально не изменится. Зааффектится только код с unsafePerformIO

Линейность есть и в Identity

От реального мира абстрагируемся потому, что там перестаёт работать referential transparency например, и ленивость пропадает. И чтобы можно было рассуждать об остальном коде, он отделён от IO насовсем - поэтому нельзя сделать runIO безопасно, только unsafe

То, что IO "в хаскеле" не "выполняется", это объективный факт, всё таки. Любые порождаемые значения внутри IO приведут к ожидаемому эффекту тогда и только тогда, когда их ВЕРНЁТ main - вернёт рантайму, который уже "выполнит". До тех пор, пока main не вернёт значение, значение - первокласное, его можно дублировать, класть в чистые типы, возвращать из чистых функций, не боясь, что где-то не там что-то в консоль напечатается или откроется несуществующий файл

Или портал в ад

Или ракеты запустятся

То, что IO "в хаскеле" не "выполняется", это объективный факт, всё таки. Любые порождаемые значения внутри IO приведут к ожидаемому эффекту тогда и только тогда, когда их ВЕРНЁТ main - вернёт рантайму, который уже "выполнит". До тех пор, пока main не вернёт значение, значение - первокласное, его можно дублировать, класть в чистые типы, возвращать из чистых функций, не боясь, что где-то не там что-то в консоль напечатается или откроется несуществующий файл

Это ровным счётом ничего не значит, любая State монада так себя ведёт. Просто, очевидно, что main оборачивается runState, и всё. Во многих ЯП входная точка чем-нибудь обёрнута, чай не ассемблер

Я и не спорю. Я имел в виду, что вычисление в IO конструирует значение, которое потом - за пределами программы - выполнится. Как и в случае со State, где конструируется пайплайн, через который будет протащен state

Единственная причина существования IO состоит в том, что RealWorld существует только в линейной форме, а в хаскеле этот факт без тайпкласса никак не записать. И всё

IO можно представить в виде Writer, который копит [IOAction]

хотя больше на State таки похоже

в [IOAction] не получится сделать ветвление в зависимости от состояния мира...

Только если дерево накапливать

В моё время IO был явно записан как "State RealWorld a" :) Как щас хз

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

поэтому когда мы пишем foo = print 42 >> print 24 никакой печати не происходит на момент определения - просто конструируется значение

Значение типа Print 42 (\() -> Print 24 (\() -> Done))

Или обернуто все во free?

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

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

\world -> (let newWorld = with world (Print 42) in \world -> ...

И правильно говорить на языке редукций, если мы хотим не аналогии строить, а "понимать сущность языка"

Или обернуто все во free?

Незачем оборачивать во Free, т.к. интерпретатор всегда один

И правильно говорить на языке редукций, если мы хотим не аналогии строить, а "понимать сущность языка"

Согласен

Не хватает @qnikst

Да, он с 10 числа не показывается

Аппликатив почти как монада, только тензор не compose, а day convolution.

мне нравится альтернативное определение Applicative через <++> :: f a -> f b -> f (a, b), без аппликаторов если ты рассматриваешь f как какой-то эффект, то получается, что <++> просто выполняет оба эффекта и ничего не делает с самими значениями. Что-то вроде моноида. В некоторых случаях там вообще напрямую моноид проглядывает – ну например Const x a у тебя будет аппликативом, если x моноид, и тогда <++> или <*> эти иксы тупо сложит: > :t (<*>) @(Const String) (<*>) @(Const String) :: Const String (a -> b) -> Const String a -> Const String b > Const "foo" <*> Const "bar" Const "foobar" как понять списки через эффекты или контексты, я без понятия (у меня никогда не получалось нормально), поэтому я просто запомнил, что со списками обычно можно твердить про себя “декартово произведение, декартово произведение” и вроде обычно работает. Есть ещё много штуковин, которые через эффекты мне сложно понять, и там приходится тоже запоминать, что будет делать Applicative/Monad

^ поэтому такое его понимание самое близкое к формализации

А любой аппликативный функтор является также и монадой, потому что day convolution можно конвертировать в compose: dayToCompose :: (Functor f, Functor g) => Day f g a -> Compose f g a dayToCompose (Day fb gc k) = Compose ( fb <&> \b -> gc <&> \c -> k b c)

> любой аппликативный функтор является также и монадой

ну нет, например

не например

а прям очень точно

но любая монада — это аппликативный функтор

day convolution это вообще что-то дикое

Wait, wat. Реализуй instance Monad ZipList, например

> любой аппликативный функтор является также и монадой

ну нет, например

не например

а прям очень точно

Местами поменяйте