どの様な話？
今まで、このブログで、
- 束因果ダイアログの矢印の事を「射」になぞらえていました、
- これは誤りだった
と反省しています。
射 (圏論) Wikipedia 日本語版で、グラフの「分岐」、「合流」について、
- 同じ事柄の別表現
を表すのに使っています。
なお、上図中の白丸は、
- 合成と呼ばれる二項演算 hom(X, Y) × hom(Y, Z) → hom(X, Z)
を意味するそうです。
しかし、「ソフトウェア開発での束因果ダイアグラムが不明瞭 １」での、「分岐」、「合流」では、
「分岐」は、
- ある原因を、お互いに重ならない、より小さな原因に分ける
か、
- 同じ原因で、複数の結果が違う場所で出来る
様な意味で使っていました。
さらに、「合流」は、
- より大きいプログラムの部分への集約（「smallで無いテストの困難さ １」）
の意味で使っていました。
因果ダイアログ（DAG）に立ち返ると
Copilot Proに、
- 因果ダイアログでの「矢印」はどういう意味でしょうか？
と聞いた所、
- Z → X なら「ZがXの原因」
- Z → Y もあれば、「ZはXとYの共通原因」
との回答を得ました、「分岐」について、束因果ダイアログは（当然）、
- 因果ダイアログ”寄り”だった
と気付かされました。
逆もまた真？
プログラミング”寄り”の人間からすると、「分岐」、「合流」の意味論は、後者の方が自然だと思います。
しかし数学”寄り”の人間からすると、前者の方が自然なのかも知れません。
- 可換で使いやすい合成のみがプログラムの本質だ
と思っていたのでは無いかと仮定すると、関数型プログラミングを主張していた人間の振る舞いを、かなり説明出来るからです。
そして、その仮定からすると、
- 合成のみが本質だとすると、プログラミングのかなりの部分を飛ばす
事になると思います。
すなわち、束因果ダイアログで言う、
- 「分岐」は、
- 何で思いつくのか？（設計段階）
で、
- 「合流」は、
- 何で自動で動くのか？（運用を考慮した実装段階）
を表し、それらは、関数型プログラミングを主張していた人間から漏れていた、まさにその部分を表すからです。
「合成」は何処へ行く？
プログラミング寄りの人間からすると、「合成」は、
- 合成し切ったものをもっぱら用い、
- 合成の各”部分”は等閑視（なおざりに）する
のだと思います。プログラミング寄りの人間からすると、そちらの方が感覚的に、よりしっくり来ると思います。
何て呼べばいい？
と有るのですし、射の概念のこの部分は、束因果ダイアログでも合致するので、
- 矢印の事は、
- 射改め、関係
と呼びたいと思います。
結論
これからも「何を飛ばしていたのか？」が不詳な状況でプログラミングが嫌いになる人は存在し続けることでしょう。
