「広義の」が落ちぶれていく様
関数型プログラミングなどは、
- 関数という言葉を再定義し、
- 「広義の」とする事で、
- 見通しを良くしよう
のでは無いかとポストモーテム的に思います。
しかし、
- プログラミング言語の「関数」の定義の強固さに敗れ
たとしか思えません。「テスト」も同様です。
プログラミングに絡む場合、「広義の」は敗れてすたこらさーとなるのが運命です。
「射」も同様では？
確かに最初の定義（「構造保存写像を一般化した圏論上の概念である。」 射（圏論） Wikipedia 日本語版）では、
- とても同格と言えない「原因→結果」の矢印も射といえそう
ですが、数学的に取り扱う場合、
- 矢印の前と後の両方とも、同じ数学的対象（テストと、テスト対象プログラムの様な）
だと思います。
数学では、矢印の前後が同じ数学的対象で無い射は扱っていないと思います。
ここで、
- 射という言葉を再定義し、
- 「広義の」とする事で、
- 見通しを良くしよう
とすると、数学での定義の強固さに敗れ、同じ事になると思います。
射をプログラミング関連の議論で使うのは、同じ轍を踏む可能性が有ります。
もっと単純化しても良いのでは？
グラフの「分岐」、「合流」（射 (圏論) Wikipedia 日本語版）に関するグラフですが、
束論的束構造の因果ダイアログでは、
- 「分岐」は、上位の原因が下位の原因（結果）に別れていく様で、
- 矢印の前と後で、同じ数学的対象とは言えない
- 射という言葉を広義化して使ってはいけない
と思いますが、
- 「合流」では、同じ数学的対象だが
- 射よりも、もっと限定的な言葉を使った方が良いかも
と思いました。
- たまたま同じタイミングで動く手続き（関数も含めた、プログラムの部分）である、
- 1-1と1-2が、3になる
のは、「合流」は、加法イデアルや乗法イデアルとかの方が合っている可能性が有ります。
結論
とにかく、プログラミングや数学で、「広義の」を企てるのは良く無いです。
合成なども、「広義」をしようとして、まさに敗退しようとしている最中だと思います。
これからも「型駆動開発の問題点」でプログラミングが嫌いになる人は存在し続けることでしょう。
