мне стало более понятно, когда я про free почитал

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

у любого контейнерного типа есть эффект

Объясни пожалуйста

ну вот Identity, например... :D

Возможно, сегодня будет тот самый день, когда мою голову пошатнет понимание

Возможно, сегодня будет тот самый день, когда мою голову пошатнет понимание

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

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

у любого контейнерного типа есть эффект

Не эффект, а контекст

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

+1

мне нравится альтернативное определение 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

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

Чтобы понять про аппликатив можно почитать пейпер

http://www.staff.city.ac.uk/~ross/papers/Applicative.pdf

В "книжке со слоном" вполне понятно вводятся последовательно Ф, АФ и затем М

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

ну как бы это видно и управляемый эффект только в последнем (a -> b) f(a -> b) (a -> f b)

монада не "управляет" эффектом, она просто его "сохраняет"

не, эффектом управляет программист, что пишет эти стрелки Клейсли

ага

Бартош в каком-то из подкастиков типа Functional Geekery неплохо про монады рассказывал "для новичков"

ну у него есть курс по хаскелл и 2 части по ТК

https://www.functionalgeekery.com/episode-69-bartosz-milewski/ вот этот выпуск

ну у него есть курс по хаскелл и 2 части по ТК

ещё есть серия статей с клевыми рисунками :)

ага) со свинками и слониками

В книжке со слоником перед монадой шел моноид, емнип. Как вычисления со стартовой точкой.

лучше расскажите про профунктор) и все эти звезды, козведы, клоуны и все такое

Ну профунктор имхо как-то намного проще понять, чем аппликатор (понять смысл)

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

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

Как использовать паттерн, если не понимаешь, что он такое

Обычно же до паттернов доходишь сам, а потом узнаешь, что он уже формализован

да можно и не понимать, обычно из type signature всё понятно

типы помогут

паттерны это гавно из ооп

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

нам не нужны паттерны, нам нужны бест практисы

Паттерн это шаблон

Независимо от тогг, где он

монада это паттерн?

Тайпкласс и паттерн почти одно и то же

Да

ну-ну

ок)

Любой тип, который имеет шабонные (общие) функции ретурн и бинд - монада

Так почему это не паттерн

ну ок, но зачем на это смотреть как на паттерн?

Тут пример использования слова без его понимания (за что ты топишь). Слово паттерн не привязано не то, что к ооп, но и к программированию в целом

я тут как бы за превосходство интуиции над пониманием.

паттерны это тоже больше про интуицию, а не про понимание

А как смотрят на паттерн?) Я меня нет какого-то особого взгляда на шаблоны, это просто нейкий способ вынести в абстракцию (тайпкласс) общие принципы

если интуиция не правильная, то скорее всего сработает тайпчекер и ты получишь ошибку

А как смотрят на паттерн?) Я меня нет какого-то особого взгляда на шаблоны, это просто нейкий способ вынести в абстракцию (тайпкласс) общие принципы

для этого нужно понимание или достаточно интуиции?

Сложный вопрос) Понимание же всегда в приоритете, нет?

Сложный вопрос) Понимание же всегда в приоритете, нет?

Так вот мой поинт в том, что если это так, то это надо исправить.

Блин вообще извините, я выпил и не понимаю о чем говорю

Да, я тоже

Всему виной вот эти заигрывания с интуицией

Я ещё книжку по интуиционистской логике сейчас читаю, хоть это и не про то немного

нахрен интуицию, даёшь практику

Мысль, которая крутится в моей голове - аппликаторы - не самостоятельный класс, а некое расширение/дополнение других типов, в которых есть возможность хранить внутри функцию

Например функторв

просто пишешь код, а потом раз - вроде понял, в чём суть

Потому что зачем оборачивать функцию в пьюр просто так я не понимаю.

Да, такой подход обычно помогает

просто пишешь код, а потом раз - вроде понял, в чём суть

вот это "вроде понял" и есть интуиция. ключевое слово "вроде".

Но вот я поработал с парсеком, использовал аппликаторы часто

Но вот я поработал с парсеком, использовал аппликаторы часто

работа с парсеком и схожими либами прокачивает эту интуицию неплохо

И не пришло понимание

ERROR: S client not available

Потому что зачем оборачивать функцию в пьюр просто так я не понимаю.

дык их никто просто так не оборачивает

смари, есть у тебя ф-ция от двух аргументов: add :: Int -> Int -> Int

И не пришло понимание

как что-то плохое

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

и есть пара вычислений, которые вычисляют числа какие-то, но могут и не вычислить

a :: Maybe Int и b :: Maybe Int

Мол функция обернута, хреново, но ниче, тип реализует аппликатор и все збс

Ага

Ага

яркий пример liftA2

и тебе надо в случае успеха всё сложить

Ну реализация через бинды мне кажется более естественной

ну тут и получается add <$> a <*> b

Особенно через do

do - это синтаксис

сахарок причём

Ну я не к тому. Я к тому, что выразить через бинды естественнее имхо, а с do это еще и выглядит не страшно

https://gist.github.com/kana-sama/387cf858097ed46610eca280229966fe

Вот тут много такой хернм

Там бы liftA4 зашел, но его нет)

ахах, типичная дискуссия хаскеллистов

Блин вообще извините, я выпил и не понимаю о чем говорю

Да, я тоже

Аппликатив для того и нужен, чтобы не делать все эти liftAN

Отдельные лифты с небольшим N остаются только потому, что они работают быстрее (минус одно заворачивание и разворачивание)

Аппликатив - это урезанная монада. В отличие от монады, где ты вешаешь коллбэки на контейнер,и последующие вычисления зависят от предыдущих - к аппликативу ты не можешь прикрепить коллбэк, ты можешь только склеить два контейнера. Зато эти два контейнера могут разрешаться результатом любом порядке. Итак: аппликатив - дерево вычислений (зависимостей?), монада - последовательность вычислений. Так я это вижу.

($) :: (a -> b) -> a -> b (<$>) :: Functor f => (a -> b) -> f a -> f b (<*>) :: Applicative f => f (a -> b) -> f a -> f b Краткая суть

Не надо забивать неокрепшим умам голову контейнерами и колбэками! Ничего этого нет! Именно из-за плохих аналогий такой отстой с монадными туториалами

Монада просто позволяет делать композицию типов определенного вида, аппликатив позволяет применять функции определенного вида. При этом "определённый вид", это просто ещё одна переменная в типе. Всё

Что уж там конечный программист положит в переменную типа - это его дело. Дело монады дать законы, соблюдая которые, программист получит нормальную композицию

И тем монада и отличается от сферического паттерна, что имеет законы.

Без законов был бы просто интерфейс для навешивания коллбэков

($) :: (a -> b) -> a -> b (<$>) :: Functor f => (a -> b) -> f a -> f b (<*>) :: Applicative f => f (a -> b) -> f a -> f b Краткая суть

($) :: (a -> b) -> a -> b (<$>) :: Functor t => (a -> b) -> t a -> t b (<*>) :: Applicative t => t (a -> b) -> t a -> t b (=<<) :: Monad t => (a -> t b) -> t a -> t b :)