Appadativesは構成しますが、モナドは構成しません

Applicativeは構成しますが、モナドは構成しません。

上記のステートメントはどういう意味ですか？そして、いつ他の方が好ましいのですか？

タイプを比較すると

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

2つの概念を区別する手がかりがわかります。(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

いくつかの効果の結果を使用して、2つの計算（たとえば、ミサイルの発射と休戦への署名）を決定しますが、

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との間で選択するために値 2つの計算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ます。Alexandre Cが言うように、適切なものがあれば

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

レイヤー間の干渉がないためです。

Monad同様に、いつsの追加のパワーが本当に必要なのか、いつApplicativeサポートする厳密な計算構造で問題を回避できるのかを認識するのは良いことです。

ちなみに、モナドの作成は難しいですが、必要以上に多いかもしれません。タイプm (n v)で計算を示しm次いでコンピューティング、効果- nの効果- v-value、m前効果-が完了n効果-は、（用したがって必要開始しますswap）。m-effectsとn-effects を交互に挿入したいだけの場合、コンポジションは多すぎて質問できないでしょう

Applicativeは構成しますが、モナドは構成しません。

モナドは作成しますが、結果はモナドではない可能性があります。対照的に、2つのアプリケーションの構成は必ずアプリケーションです。元のステートメントの意図は「適用可能性は構成するが、モナドネスは構成しない」であったと私は推測します。「作文でApplicativeは閉鎖されており、そうでMonadはない」と言い換えた。

applicatives A1とA2がある場合、タイプdata A3 a = A3 (A1 (A2 a))もapplicativeです（このようなインスタンスは一般的な方法で記述できます）。

一方、モナドがM1ありM2、型data M3 a = M3 (M1 (M2 a))がモナドであるとは限りません（合成のための、>>=またはjoin合成のための賢明な一般的な実装はありません）。

1つの例として、型があります[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このタイプの正しい関数は存在できません。

残念ながら、私たちの本当の目標であるモナドの構成はかなり難しいです。..実際、ある意味で、2つのモナドの演算のみを使用して上記のタイプの結合関数を構築する方法がないことを実際に証明できます（証明の概要については付録を参照してください）。したがって、コンポジションを形成したい唯一の方法は、2つのコンポーネントをリンクする追加の構造がある場合のみです。

モナドの作成、http： //web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

分配法の解l：MN-> NMで十分

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

これらのマップを作成するのに十分な構造があります。ただし、Eugenia Chengが観察しているように、どちらかの構造の単一性を保証するために、六角形の条件（Yang-Baxter方程式の表現に相当する）が必要です。実際、六角形の条件では、2つの異なるモナドが一致します。