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

+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 всё понятно

типы помогут

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

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

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

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

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

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

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

Да

ну-ну

ок)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, я тоже

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

смари, есть у тебя ф-ция от двух аргументов: 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 зашел, но его нет)

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

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