モナドはエンドファンクターの範疇にあるモノイドにすぎません。啓蒙とは何でしょうか?

Question

言葉遊びごめんなさい。ちょっと混乱していますが、 含意 主張の、したがって質問です。

背景： 私はさまざまな理論的基礎を理解するために圏論に挑戦しました。 カテゴリ構造 および関数型プログラミング (FP) との関連性。Cat と FP の交差点における「最高の宝石」の 1 つは、次のステートメントであると (私には) 思われます。

A monad is just a monoid in the category of endofunctors

とは何ですか 大したこと この観察について、またそのプログラム/設計への影響は何ですか?のようなソース シグペ そしてFPに関する多くのテキストは次のことを暗示しているようです。 驚くべきこと この概念については理解できましたが、おそらく私にはそれがほのめかされている微妙さが理解できませんでした。

私はそれを次のように理解しています。

何かを知るということは、 モノイド 内で作業できるという事実を推測することができます。 マップリデュース 操作の結合性により、計算を任意の順序で分割/結合できるように設定します。つまり、 (a1+a2)+a3 == a1+(a2+a3). 。また、これをマシン間で分散し、高度な並列化を実現することもできます。（したがって、私は精神的に次の状態に戻ることができました） theoretical construct -> computer science understanding -> practical problem solving.)

私にとってはそうでした 明らか (Cat を勉強した結果) モナドが モノイダル エンドファンクターのカテゴリーにある構造。しかし、このようなメンタル モデルを使用してコーディングしている場合、このことからどのようなことが示唆されるのでしょうか。また、そのようなメンタル モデルを使用してコーディングする場合、そのプログラム/デザイン/エンジニアリングへの影響は何でしょうか?

私の解釈は次のとおりです。

• 理論的な意味: 彼らの中心にあるすべての計算可能な問題は、 モノイダル ある意味で。
  • これは正しいです？そうであれば理解できるのですが、 啓発. 。これは、計算のチューリング/ラムダ モデルだけから来ている場合には明らかではない、計算可能な問題の概念/構造を理解するための異なる視点であり、安心できます。
  • さらに何かあるでしょうか？
• 実際的な意味: 単に事例を提供するだけなのでしょうか？ do-プログラミングの記法スタイル?つまり、物事がモノイダルであれば、 do/for Haskell/Scala で構築します。そうですか？たとえモノイド基礎について知らなかったとしても、その必要はありません。 呼び出す の モノイド性 バインドしてからこの主張をするには >>= そして flatMap 構成要素は結合するように定義されます。それで何が与えられるのでしょうか？それとももっと関係があるのでしょうか？ 折り畳み性 モナド構造と それ 間接的なものです 啓発 それが暗示されているのですか？

質問: ここで何が足りないのでしょうか？それは単に、 認識 モナドは一般化されたモノイドであり、 組み合わせた モノイドのようなマップリデュース操作と同様の順序でしょうか?モノイド特性について知ることはどのように役立ちますか 改善する コード/デザインは何かありますか？この違いを示す前後の良い例は何ですか (モナド/モノイド性について知る前と後)。

Answer 1

この答えはあなたが探しているものではないかもしれません。つまり、おそらくこの特徴付けの重要性がここでは過度に強調されていると思います。引用

X のモナドは、X のエンドファンクターの範疇にあるモノイドにすぎません。

元々はマクレーンのものです 現役数学者のカテゴリ, ここでは、モナドの定義を直感的に理解するのに役立ちますが、これだけでは最初はまったく馴染みのないものに思えるかもしれません。それを特定のモノイド範疇のモノイドとして特徴付けることで、読者に別の視点が与えられます。モナドに関する章は実際にはモノイド圏に関する章よりも前にあることに注意してください。このコメントは正確であるというよりも、役立つことを目的としています (正確になるのは後になってからです)。

その後、この引用はジェームズ・アイリーの悪名高い記事で言い換えられた 短く、不完全で、ほとんどが間違っているプログラミング言語の歴史.

モナドはエンドファンクターの範疇のモノイドにすぎません。何が問題なのでしょうか?

記事にあるように、文脈を無視して提示されているのは、楽しむことを目的としています。それ以来、この引用は関数型プログラミング コミュニティでミームになりました。その主な理由は、関数型プログラミングに対する重要な洞察ではなく、それが面白いからです (ただし、関数型プログラマの好奇心を刺激し、圏論の素晴らしい世界に引き込むのにも役立ちます) ）。私の見解では、この特徴付けは有益で興味深いものではありますが、その人気から想像されるほど重要ではありません。

ただし、この特徴付けから得られる洞察がまったくないというわけではありません。まず、あなたが指摘したように、乗算と単位を伴うモナドの表現は明らかにモノイドを示唆していますが、バインドと戻り演算を伴う Kleisli の表現はそうではないことを指摘しておきます。これは関数型プログラミングでは一般的な Kleisli 表現であるため、確かにこの観点からはモノイドとしての特徴付けの方が興味深いです。

理論的な観点から見ると、コンピューター サイエンス (および数学) における多くの自然構造はモノイダルであるという洞察の 1 つが得られます。モナドの観点から（特にモナドとモナドの関係） デカルトオペラ そして ローヴェレ理論)、モノイド構造は置換構造 (等価、合成構造) に対応します。置換はコンピュータ サイエンスのいたるところで行われます (たとえば、型理論におけるキャプチャを回避する置換や、ツリーの接ぎ木など)。モナドはもう 1 つの例にすぎません。

問題のステートメントを形式的に理解することは啓発的ではないかもしれませんが、モナドのさまざまな使用方法を確認できるため、モナドに関するさまざまな視点を理解することは啓発的であることをお勧めします。コンテナとして、代数構造の記述、多成分系の記述など)。さまざまな光の下で見ることができなければ、それらがどれほど頻繁に現れるかを理解するのは難しいかもしれません。この意味で、モノイドとしてのモナドは 1 つの観点にすぎません (そしておそらく最も啓発的なものではありません)。

最後に、モナド自体は一般的に純粋関数型プログラミングにおいて非常に有用であることは間違いありませんが、モナドをモノイドとして見るという視点自体が役立つかどうかはわかりません。私は、Kleisli の視点が、偶然にも同等ですが、ここで最も啓発的な視点であると思います。

要約すると、この応答は少し残念かもしれません:この関係を理解することは、実際にはそれほど役に立たず、啓発にもならないと思います（つまり、プログラミング用）。ただし、モナドを理論的に考えるときに、他の視点とともに覚えておくと便利な視点です。