どの様な話?
というのですが、関数型プログラミングの、関手やモナドは、
- 実際の機能をもたらす関数を引数として与える
だけに堕してしまっています(単なるそれだけの意味)。
これでは、圏論の無駄遣いです。
それらの一覧
Copilot Proに2025/9/29 PM3頃、
と聞いた所、

上記の様な一覧を出してもらえました。
そして、説明として、
- モナドは自己関手なので、圏の各対象 𝐴 に対して新たな対象 𝑇(𝐴) を割り当て、射 𝑓:𝐴→𝐵 に対して𝑇(𝑓):𝑇(𝐴)→𝑇(𝐵) を定義します。
- つまり、モナドは対象と射の「変換器」として働きます。
というのです。
つまらなくなるポイント
射が、
- 原因(仕様)→ 結果(プログラム)
で有る場合(束因果ダイアログの部分である場合)、
- T(原因(仕様)) → T(結果(プログラム))
というのは余り、意味のある表現にはならないと思います。
束因果ダイアログのバリエーションは、つながり方自体が変化する事で起こるからです。関手(構造保存な)など、余計なお世話になります。
場合、関手もモナドも空論になってしまうと思います。
2択を強いられる
集合圏で、自己関手の場合、すなわち、
- 関手やモナドが、実際の機能をもたらす関数を引数として与える
だけに堕してしまっている(単なるそれだけの意味)場合に限り、
- 関手もモナドも実態の有る議論になる
のです。
逆に、
- 仕様からプログラムへの射
なんて議論の際には、関手もモナドも空論になりますが、これはこれで、圏論を最大限、活用している結果だと思います。
結論
関手もモナドも圏論の無駄遣いの末、MAP関数の基礎とか関数を引数で渡す基礎とかになっているのかも知れませんが、
代わりに、対象が「整数型と実数型の組み合わせ」のみになるという超絶改悪になっています。
対象を固定して関手やモナドを活かすか、それらを空論にして対象にバリエーションを持たせるかの2択になってしまうのだと思われます。
これからも「圏論の無駄遣い」でプログラミングが嫌いになる人は存在し続けることでしょう。