Аппликативы составляют, а монады - нет

Аппликативы составляют, а монады - нет.

Что означает приведенное выше утверждение? А когда одно предпочтительнее другого?

Если сравнить типы

(<*>) :: Applicative a => a (s -> t) -> a s -> a t
(>>=) :: Monad m =>       m s -> (s -> m t) -> m t

мы понимаем, что разделяет эти два понятия. То, что (s -> m t)в типе (>>=)показывает, что значение в sможет определять поведение вычисления в m t. Монады допускают взаимодействие между слоями значений и вычислений. (<*>)Оператор не допускает таких помех: функция и аргумент вычисления не зависят от значений. Это действительно кусается. Сравнить

miffy :: Monad m => m Bool -> m x -> m x -> m x
miffy mb mt mf = do
  b <- mb
  if b then mt else mf

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

iffy :: Applicative a => a Bool -> a x -> a x -> a x
iffy ab at af = pure cond <*> ab <*> at <*> af where
  cond b t f = if b then t else f

который использует значение abдля выбора между значениями двух вычислений atи af, выполнив оба, возможно, к трагическим последствиям.

Монадическая версия в основном полагается на дополнительную (>>=)возможность выбора вычисления из значения, и это может быть важно. Однако поддержка этой силы затрудняет сочинение монад. Если мы попытаемся построить двойную привязку

(>>>>==) :: (Monad m, Monad n) => m (n s) -> (s -> m (n t)) -> m (n t)
mns >>>>== f = mns >>-{-m-} \ ns -> let nmnt = ns >>= (return . f) in ???

мы зашли так далеко, но теперь наши слои перемешаны. У нас есть n (m (n t)), поэтому нам нужно избавиться от внешнего n. Как говорит Александр С, мы можем это сделать, если у нас есть подходящий

swap :: n (m t) -> m (n t)

переставить nвнутрь и joinего на другое n.

Более слабое «двойное применение» гораздо легче определить

(<<**>>) :: (Applicative a, Applicative b) => a (b (s -> t)) -> a (b s) -> a (b t)
abf <<**>> abs = pure (<*>) <*> abf <*> abs

потому что нет интерференции между слоями.

Соответственно, хорошо понимать, когда вам действительно нужна дополнительная мощность Monads, а когда можно обойтись жесткой структурой вычислений, которая Applicativeподдерживает.

Заметьте, кстати, что, хотя составление монад сложно, это может быть больше, чем вам нужно. Тип m (n v)указывает вычисление с m-effects, затем вычисление с n-effects до v-value, где m-effects заканчиваются до начала n-effects (отсюда необходимость swap). Если вы просто хотите чередовать m-effects с n-effects, то композиция - это слишком много, чтобы просить!

Аппликативы составляют, а монады - нет.

Монады действительно составляют, но результатом может быть не монада. Напротив, композиция из двух аппликативов обязательно является аппликативом. Я подозреваю, что намерение первоначального утверждения заключалось в том, что «аппликативность составляет, а монадность - нет». Перефразируя, « Applicativeзакрыто по составу и Monadне является».

Если у вас есть аппликативы A1и A2, тогда тип data A3 a = A3 (A1 (A2 a))также является аппликативным (вы можете написать такой экземпляр в общем виде).

С другой стороны, если у вас есть монады, M1и M2тогда тип data M3 a = M3 (M1 (M2 a))не обязательно является монадой (нет разумной универсальной реализации для композиции >>=или joinдля нее ).

Одним из примеров может быть типа [Int -> a](здесь мы составляем конструктор типа []с (->) Int, оба из которых являются монады). Вы легко можете написать

app :: [Int -> (a -> b)] -> [Int -> a] -> [Int -> b]
app f x = (<*>) <$> f <*> x

И это относится к любому аппликативу:

app :: (Applicative f, Applicative f1) => f (f1 (a -> b)) -> f (f1 a) -> f (f1 b)

Но толкового определения

join :: [Int -> [Int -> a]] -> [Int -> a]

Если вы не уверены в этом, рассмотрите это выражение:

join [\x -> replicate x (const ())]

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

К сожалению, наша настоящая цель - составление монад - намного сложнее. .. Фактически, мы действительно можем доказать, что в определенном смысле нет способа построить функцию соединения с указанным выше типом, используя только операции двух монад (схему доказательства см. В приложении). Отсюда следует, что единственный способ, которым мы можем надеяться сформировать композицию, - это наличие дополнительных конструкций, связывающих два компонента.

Составление монад, http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

Достаточно решения l: MN -> NM по распределительному закону

гарантировать монадичность НМ. Для этого вам понадобится агрегат и мульт. я сосредоточусь на мульт (единица измерения - unit_N unitM)

NMNM - l -> NNMM - mult_N mult_M -> NM

Это не гарантирует, что MN является монадой.

Однако важное наблюдение вступает в игру, когда у вас есть решения по закону распределения.

l1 : ML -> LM
l2 : NL -> LN
l3 : NM -> MN

таким образом, LM, LN и MN - монады. Возникает вопрос, является ли LMN монадой (либо по

(MN) L -> L (MN) или через N (LM) -> (LM) N

У нас достаточно структуры, чтобы делать эти карты. Однако, как отмечает Юджиния Ченг , нам нужно гексагональное условие (которое представляет собой представление уравнения Янга-Бакстера), чтобы гарантировать монадичность любой конструкции. Фактически, с условием гексагональности две разные монады совпадают.