リーダー、ライターモナド

してみましょうあることCCC。してみましょうの製品bifunctorも。通り猫が CCCである、我々はカレーできる： $C$ $(\times)$ $C$ $(\times)$

$curry (\times) : C \rightarrow(C \Rightarrow C)$

$curry (\times) A = \lambda B. A \times B$

ファンクターカテゴリは、通常のモノイダル構造があります。 $C \Rightarrow C$ でモノイド中モナドである。 $C \Rightarrow C$ $C$ 有限積をモノイド構造と見なします。 $C$

$curry (\times) 1 \cong id$

$\forall A\ B. curry (\times) (A\times B) \cong (curry (\times) A) \circ (curry (\times) B)$

したがって、はモノイド構造を保持するため、モノイドにモノイドを、コモノイドをコモナに輸送します。つまり、任意のモノイドをモナドに転送します（定義を見てくださいはモノイドでなければなりません）。同様に、それは輸送対角線comonoidにCoreaderの comonadを。 $(curry (\times))$ $w$ $(Writer\ w)$ $w$

さて、具体性のために、Writerの構築を展開します。

ベギン。実際には、Haskellでは単に異なる名前を持っています。我々は持っているHaskellはモノイド： $Writer = Coreader = curry(\times)$ $\langle w, mappend, mempty\rangle$

$mappend : w\times w \to w$

$mempty : 1 \to w$

ライターはファンクターなので、やなどの射もマップする必要があります。Haskellでは無効ですが、次のように記述します。 $mappend$ $mempty$

$Writer\ mappend : Writer(w\times w) \to Writer\ w$

$Writer\ mappend$ は自然な変換であり、射である。プロパティにより、それは関数でありを取り射を与えます： $C\Rightarrow C$ $curry(\times)$ $a \in Ob(C)$ $C$

$Writer\ mappend\ a = mappend\times(id(a)) : Writer (w\times w) a \to Writer\ w\ a$

非公式には、は、タイプコンポーネントを合計しそのままポンプます。これはまさにHaskellのWriterの定義です。1つの障害は、モナドに必要なことです $Writer\ mappend\ a$ $w$ $a$ $\langle Writer\ w,\mu,\eta\rangle$

$\mu : Writer\ w \circ Writer\ w \to Writer\ w$

すなわち、型の非互換性。しかし、これらのファンクターは同型です： a自然な同型である有限積の通常のアソシエー。次に、を定義します。私は建設省略経由。 $Writer (w\times w) = \lambda a. (w\times w)\times a$ $\cong \lambda a. w\times(w\times a) = Writer\ w \circ Writer\ w$ $\mu$ $Writer\ mappend$ $\eta$ $mempty$

ライターはファンクターであり、可換図を保存します。つまり、モノイド等式を保存します。したがって、 =のモノイドを =モナドの。終わり。 $\langle Writer\ w,\mu,\eta\rangle$ $(C\Rightarrow C)$ $C$

何についてのリーダーとCowriter？Coreaderの定義で説明されているように、リーダーはCoreaderに付随しています。上記のリンクを参照してください。同様に、CowriterはWriterに付随しています。Cowriterの定義が見つからなかったので、表に示す類推でそれを作り上げました。

代替テキスト

{- base, Hackage.category-extras -}
import Control.Comonad
import Data.Monoid
data Cowriter w a = Cowriter (w -> a)
instance Functor (Cowriter w) where
    fmap f (Cowriter g) = Cowriter (f . g)
instance Monoid w => Copointed (Cowriter w) where
    extract (Cowriter g) = g mempty
instance Monoid w => Comonad (Cowriter w) where
    duplicate (Cowriter g) = Cowriter
        (\w' -> Cowriter (\w -> g (w `mappend` w')))

以下は、それらの（コ）モナドの簡略化された定義です。fr_ob Fはオブジェクト上のファンクターFのマッピングを示し、fr_mor Fは射型上のファンクターFのマッピングを示します。はモノイドオブジェクトがあります。 $\langle w,\hat{+},\hat{0}\rangle$ $C$

作家
- $fr\_ob (Writer\ w) a = a\times w$
- $fr\_mor (Writer\ w) f = \lambda \langle a_0,w_2\rangle. \langle a_0,f\ w_2\rangle$
- $\eta a = \lambda a_0. \langle a_0, \hat{0} \rangle$
- $\mu a = \lambda \langle \langle a_0,w_1\rangle,w_0\rangle. \langle a_0, w_0\hat{+}w_1\rangle$
読者
- $fr\_ob (Reader\ r) a = r\to a$
- $fr\_mor (Reader\ r) f = \lambda g\ r_0. f (g\ r_0)$
- $\eta a = \lambda a_0\ r_0. a_0$
- $\mu a = \lambda f\ r_0. f\ r_0\ r_0$
コリーダー
- $fr\_ob (Coreader\ r) a = r\times a$
- $fr\_mor (Coreader\ r) f = \lambda \langle r_0,a_0\rangle. \langle f\ r_0,a_0\rangle$
- $\eta a = \lambda \langle r_0,a_0\rangle. a_0$
- $\mu a = \lambda \langle r_0,a_0\rangle. \langle r_0,\langle r_0,a_0\rangle\rangle$
コライター
- $fr\_ob (Cowriter\ w) a = w\to a$
- $fr\_mor (Cowriter\ w) f = \lambda g\ r_0. f (g\ r_0)$
- $\eta a = \lambda f. f\ \hat{0}$
- $\mu a = \lambda f\ w_1 w_0. f (w_0\hat{+}w_1)$

問題は、の付属語がモナドではなくファンクターに関連していることです。「Coreader is comonad」「Reader is a monad 」および「Writer is a monad 」「Cowriter is comonad」という付属語の意味がわかりません。 $C$ $\to$ $\to$

リマーク。より多くのコンテキストを提供するのに苦労しています。いくつかの作業が必要です。特に、カテゴリーの純度が必要な場合、それらの（コ）モナドはプログラマーに導入されました。しつこい！;）

functional-programming pl.programming-languages ct.category-theory

— ベロア
ソース

オファー：テーブルのスクリーンショットを撮って、ここに画像を配置できます。

— MS Dousti

ここに質問をコピーしてください。

— デイブクラーク

人々は、その理由を説明するコメントを投稿する必要があります。

— スレシュヴェンカト

@Ohad。私はその質問をより文脈的に提供しようとするためにその変更を導入したことを告白します（元々参照されていたブログ投稿で発見されたように）。たとえば、リーダーとライター、コリーダーとコライターがカテゴリー用語またはHaskell、あるいはその両方で定義されていることを定義することにより、ベロアは自分の質問を自己完結させるためにもっと努力するべきだと思います。

— デイブクラーク

@beroal：私が意味したのは、Haskellを日常的に使用していないので、Haskellコードを解析してCTに移行することは私にとって、そしておそらく他の人にとっても簡単ではないということです。純粋に質的観点で質問を言い換えすることで、あなたは...迅速な答えを受ける可能性が高い

— オハッドKammar

回答:

はい、モナドに右随伴場合、自動的に共通構造を継承します。 $M : C \to C$ $N$ $N$

これを理解するための一般的なカテゴリー理論の設定は次のとおりです。ましょう及び二つのカテゴリーこと。書き込みためcategeoryからファンクタのに対する。そのオブジェクトはファンクターであり、その射は自然な変換です。書き込みの完全なサブカテゴリのために $C$ $D$ $\mathrm{Fun}(C, D)$ $C$ $D$ $\mathrm{Fun}^L(C, D)$ $\mathrm{Fun}(C, D)$ 正しい随伴を持つファンクターについて（言い換えれば、正しい随伴とそれらの間の任意の自然変換を持つファンクターを考慮します）。ファンクターの右随伴者にと書く。次いで、反変ファンクタである：もし $C \to D$ $F^R : D \to C$ $F : C \to D$ $-^R : \mathrm{Fun}^L(C, D) \to \mathrm{Fun}(D, C)$ 次いで、誘導された天然の変換がある天然の変換である。 $\alpha : F \to G$ $\alpha^R : G^R \to F^R$

場合、次いで組成物によって与えられるmonoidal構造を有しており、そう左adjointsの組成が左随伴であるため、。具体的には、、そう antimonoidal反変ファンクタです。ファンクタを装備する構造的自然変換にを適用する場合 $C = D$ $\mathrm{Fun}(C, C)$ $\mathrm{Fun}^L(C, D)$ $(FG)^R = G^R F^R$ $-^R$ $-^R$ $M$ モナドの構造では、出てくるのはコモナドです。

— リード・バートン
ソース

そして、もう一つは、これらのファンクタのいくつかは、たとえばことを言及すべきである

本当にファンクタではなく、唯一、最大の正準同型に、それは一般的に満たす関手ので擬似ファンクタのようなものではありません。それにもかかわらず、要点は有効です。

-^{R}

${-}^R$

— アンドレイバウアー

ところで、これ：

してみましょうでの製品bifunctorも。 CCCである、我々はカレーできる $(\times)$ $C$ $C$ $(\times)$

少し間違っています。1つは、通常の用語は（私が間違っていなければ）が上または上の二機能因子であるということです。「イン」は通常、カテゴリの矢印とオブジェクトを使用する構造を意味しますが、「オン」カテゴリのファンクターは、複数のカテゴリに関連する構造を指します。そして、製品のbifunctorは、デカルトカテゴリ内の構造ではありません。 $\times$ $C$

そして、これはより大きな不正確さに関係します。製品の二機能をカリー化する能力は、がデカルト閉であるとは関係ありません。むしろ、カテゴリのカテゴリである（警告を挿入）がデカルト閉であるため可能です。そのため、問題のカレーは次のようになります。 $C$ $Cat$

H o m_{C a t} (C \times D, E) ≅ H o m_{C a t} (C, E^{D})

$Hom_{Cat}(C \times D, E) \cong Hom_{Cat}(C, E^D)$

ここで、はカテゴリーの積であり、はファンクターのカテゴリーです。ただし、これは、、、およびがデカルト閉であるかどうかに関係なく機能します。私たちは聞かせたとき、我々が得ます： $C \times D$ $E^D$ $F : D \to E$ $C$ $D$ $E$ $C = D = E$

\times : C \times C \to C

$\times : C \times C \to C$

c u r r y_{\times} : C \to C^{C}

$curry_\times : C \to C^C$

しかし、これは単に次の特別な場合です。

F : C \times D \to E

$F : C \times D \to E$

c u r r y_{F} : C \to E^{D}

$curry_F : C \to E^D$

— ダン・ドエル
ソース

2 Dan Doel：はい、はい、はい、ありがとう。オリジナルの投稿beroal.livejournal.com/23223.htmlから翻訳中に私は間違いをしました。

— ベロア

adjunctionを考えてみましょう。すべてのそのようadjunctionのために我々はモナド持っともcomonad 。特に、とはエンドファンクターである必要はなく、一般的にはそうではありません（たとえば、リストモナドは、と間の無料ファンクターと忘却ファンクター間の付加です $\langle F,G,\epsilon,\eta \rangle$ $\langle GF, \eta, G\epsilon F\rangle$ $\langle FG, \epsilon, F\eta G\rangle$ $F$ $G$ $\mathbf{Set}$ $\mathbf{Mon}$ ）。

そのため、読者（またはライター）を取得し、それを随伴ファンクターに分解して、モナドと対応するコモナを生成します。つまり、ReaderとCoreader（またはWriterとCowriter）の間の接続は、探しているものではないということです。

そして、それはようカリー化を考えるのは、おそらく良いでしょう、すなわち。または、それが役立つ場合、 $-^\ast : \text{hom}({-}\times A, {=}) \cong \text{hom}({-}, {=}^A)$ $\forall X,Y.~ \lbrace f : X\times A \to Y \rbrace \cong \lbrace f^\ast : X \to Y^A \rbrace$ $-^\ast : \text{hom}({-}\times A, {=}\times 1) \cong \text{hom}({-}^1, {=}^A)$

— レン・ロマーノ
ソース

2 wren ng thornton：Setと代数構造のカテゴリーとの間の付属物に似たReaderとWriterの定義的な補助詞を知りません。または、すべてのモナドは、「MacLane。作業数学者のカテゴリ。VI。モナドと代数。「？もっと具体的に教えてください。実際、私の質問は、これらの（コ）モナドをリストモナドのようにエレガントな言葉で定義しようとする試みの結論です。

— ベロア

T

$T$

F : S e t \to M o n

$F:\mathbf{Set}\to\mathbf{Mon}$

U : M o n \to S e t

$U:\mathbf{Mon}\to\mathbf{Set}$

η : {id}_{S e t} \to U F

$\eta:\text{id}_{\mathbf{Set}}\to UF$

ϵ : F U \to {id}_{M o n}

$\epsilon:FU\to\text{id}_{\mathbf{Mon}}$

⟨ F, U, η, ϵ ⟩

$\langle F,U,\eta,\epsilon \rangle$

⟨ U F, η, U ϵ F ⟩

$\langle UF,\eta, U\epsilon F\rangle$

S e t

$\mathbf{Set}$

M o n

$\mathbf{Mon}$

⟨ F U, ϵ, F η U ⟩

$\langle FU,\epsilon, F\eta U\rangle$

ファンクター（リーダーa）と（ライターa）は随伴であり、その付加は（状態a）モナドを生じさせます。

— ベロア

「いいえ、私のポイントは、モナドとコモナドが「同じように」、すなわち、前述のように、付加によって発生するということでした」。SetとMonのカテゴリの付加からモナドとコモナを取得すると、Setでモナドを取得し、Monでコモナを取得します（異なるカテゴリ）。ただし、リーダーとライターは同じCCCカテゴリに属します。

— ベロア