#はい。そこまでは分かるのですが、そうすると、
同じ一つのモナド（IOモナド）の中で、>>= の型が
IO Char -> (Char -> IO String) -> IO String と
IO String -> (String -> IO String) -> IO String
の２通りで使われることになるのが気になりました。
これは特に問題ないことなのでしょうか？
#(>>=) :: m a -> (a -> m b) -> m b なので >>= の左辺と右辺で m (ここではIO) は同じでなければなりませんが、a と b は異なる型でも良いのです。 >>= を通過するたびに異なる型になっても問題ありません。
#ある場所で使われる >>= が、その中で a と b に矛盾がなければ OK です。
#その次に使われる >>= の a と b は、またその中で矛盾がなければ OK です。
#全体の m は、同じでなければなりません。
#Monadというのは1つの引数をとる型構成子(type constructor)の性質を抽象したものです．
#Eq や Ord のように引数をとらない型構成子の性質を抽象したものとすこし違います．
#たとえば， Maybe a という型の性質ではなくて，Maybe という型構成子がMonadのインスタンスになっているということです．
#ということは，IO String とか IO Char とかが Monad なのではなく，IO がモナドということになります．
#丁寧なご説明ありがとうございます。
どのご説明もよく分かったつもりですが、実は自分
としては十分納得できていません
現時点では、元来シンプルでフラットだったラムダ
計算や関数プログラミングにモナドという何か難解
な構造が入ってきたな／もとのままでも同じような
ことはできるのではないか／特に関数適用のような
基本的な部分を拡張するのに見合う効果があるのだ
ろうか、というようなぼんやりとした疑問がありま
す。しかしそれらは勿論私自身の不勉強が主な理由
だと思いますから、この後もご本でよく勉強させて
いただこうと思います。
#立て続けで申し訳ありませんが、もう一つ別の質問
をさせて下さい。
p.244 抽象データ型にQueueの代数的仕様があります
が、これは全体的には、joinやfrontやbackなどを
操作的に相互定義しているように読めます。
そのとき、私などには、たとえば、これでfrontが
十分定義できているのだろうか、backが十分定義で
きているだろうかと不安になるのですが、このよう
に代数的に書かれる場合、そういう不安はないもの
なのでしょうか。
#理解のプロセスとして、モナドも継続みたいなものかもしれない。わかると、当然に思えるんだけれど、わかるまでは、なにがわからないのかさえよくわからない。
#> 元来シンプルでフラットだったラムダ
> 計算や関数プログラミングにモナドという何か難解
> な構造が入ってきたな／もとのままでも同じような
> ことはできるのではないか／特に関数適用のような
> 基本的な部分を拡張するのに見合う効果があるのだ
> ろうか、というようなぼんやりとした疑問がありま
> す。
モナドの概念がはいってきたからといって何か複雑になったわけでは
ありません．今まで気づかなかった抽象化に名前が付いて新しい見方
ができるようになったということです．たとえば関数適用は従来もの
と何ら変っていません．そうではなくて，ある種の操作が実は関数適
用と類似性があることがわかった．それを関数適用の拡張と見なすこ
とで新しい見方ができるようになったということではないでしょうか．
#代数仕様は定義ではなくて，実装が満すべき性質をあらわしています．
#> これでfrontが
> 十分定義できているのだろうか、backが十分定義で
> きているだろうかと不安になる
#定義しているわけではないので，この感覚は自体はまっとうだとおもいます．
#実際の定義（実装）はこの代数仕様を満すように定義します．実装が（つまり定義が）正しく行われているかを代数仕様を使って確かめるわけです．
haskell-ja > Archives > 2012/11/06