(中断していた>>18の続き)

これがHaskellであれば、今まで培ってきた手続き型言語の知識を捨て去って、一から関数型言語の
プログラミング技法を習得する必要がある。勘違いしやすいのは、
・Haskellプログラマ --> 「モナドを使えば副作用が実現できる(= be can)」なのに対して、
・普通のプログラマ --> 　入出力やステートマシンなんて手続き型言語や正格関数型言語であれば、
　　　　　　　　　　　　ごく自然に(直感的に)記述できるけれど、Haskellでは
　　　　　　　　　　　　「同じ事をしたいだけなのに、モナドを使わなければならない(= be must)」
という認識が、現実であるということ。
モナドは負の要素であり「本来は不要だけれども、しかたなく使わざるをえない」仕掛けである事を忘れてはならない。
これが「Haskellが(現時点で)普及していない」し、「Haskellが数年のうちに普及することは有り得ない」という主張の理由。

この「モナドは負の要素でしかない」という切り口(視点)を「モナドは正の要素である(=モナドでなければ実現できない)」
という世界へと逆転させる潜在的可能性の曖昧な模索が、>>8,10で書いた妄想。妄想は妄想であって、今はまだ現実じゃない。
ただ、こういった高度に抽象化された対象、言い換えると、時間の経過や状態の変化が存在しない数学の世界を扱うには、
(「評価順序が定まらない」のではなく)評価順序を考慮せずにアルゴリズムを定義(記述)できる
Haskellのような非正格関数型言語に絶対的な優位性があるはず。また、>>10ではI/Oモナドについて書いたけど、
処理対象がメモリであってもファイルであっても統一したインターフェイスを提供できるのが、
非正格関数型ならではの(=非正格関数型でなければ実現できない)利点ではなかったのか？と思う。
（Haskellや圏論については勉強中だから、間違った推測かもしれないけど....。）