モナドの本質はつなぐ事

　言いきってしまったが、実のところ、あまり自信はない。と、エチケットペーパーを敷いてからはじめるよ。
　Haskellにおけるモナドの本質は、「つなぐ」ところにあるのではないだろうか。
　例えば、IOモナドは副作用をつなぐ事で、実行順番を指定する。Maybeモナドは途中でNothingになってしまうかもしれない計算をつなぐ。（…この表現はちょっと苦しいかも。）Listモナドは…うーん、まだよくわかってないけど。
　関数型言語においてIO（というか副作用）が行われる際に問題になるのは、実行順序だ。（副作用を行うこと自体の問題は、今は棚上げする。）評価戦略として遅延評価を採用すると、人間には実行順序がよくわからなくなる（もちろん、計算機にとっては特に問題はない。）これを解決するためには、順序関係が指定されていれば良い。例えば、リストは順序関係が決まっているので、実行順序の決定に使える。ということで、実際に昔のHaskellでは無限リストを使ってIOを行っていた。（そういう意味で、遅延評価を採用したが故に無限リストが簡単に扱えるようになった、というのはなんとなく面白いところだと思う。）しかし、リストで入出力を行うよりは、>>=で順番を指定した方が見た目にわかりやすい。
　Maybeモナドにおいても、つなぐ事が重要である事は間違いない。MaybeモナドはJust xかNothingを返す事で、失敗した際の呼出側での処理を可能にしている。まぁ、それだけでも確かに便利なんだけど、それだけならモナドにする必要はない。単なる多相型で十分だ。>>=の左側にNothingが出てきたら右側の関数は呼び出さずにNothingを式の値として返すことで、途中で失敗するかもしれない計算をそのまま>>=でつないでプログラムにすることができる。
　と、ここまで書いた所でふつうのHaskellプログラミングを読み返してみると、「どのモナドにも演算をつなぐという共通の目的がありました」と、ばっちり書いてあった。素敵。