第3回 mapからモナドを理解する
今回は「モナド（monad）」について説明します。モナドはHaskellの重要な特徴の一つなので，名前くらいは聞いたことがある人が多いでしょう。ただ，「モナドは難しい」という声もよく聞きます。 モナドとは一体なんでしょうか。前回，「HaskellはIOを取り扱うためにモナドと呼ばれる特別な仕組みを使用することで有名です」と書きました。Haskellは遅延評価を行うため，プログラマが処理の順番を確実に指定することができず，そのままでは入出力の処理には不向きです。モナドを使えば制御構造を導入できるため，この問題を解決できます。前回でいえば，(IO a -> IO a)にマッチする関数――finallyやprintThenAdd――を定義している部分がモナドに相当します。また，GHCiのプロンプトにもモナドが使われています。このように入出力操作を行うモナドの代表格が「IOモナド」です。ライブラリ
状態モナド遊び - あどけない話
状態をモナドで実現する方法を考えます。 リスト 例は簡単な方がいいので、データ構造として Lisp 風のリストを定義しましょう。 data List a = Nil | Cons a (List a) deriving Show リストは、こんな風に表せます。 Cons "c" (Cons "b" (Cons "a" Nil)) Lisp 風の cons も定義してみましょう。 cons :: a -> List a -> List a cons x xs = Cons x xs cons "c" $ cons "b" $ cons "a" Nil → Cons "c" (Cons "b" (Cons "a" Nil)) 状態を持つリスト さて、この Lisp 風のリストに、要素の数を覚えさせておきたいとしましょう。もちろん、数えれば分りますが、数えなくても一瞬で分るようにしたいのです。
「モナドは象だ(Monads are Elephants)」日本語訳 — Japanese Translation of Monads are Elephants v1.0 documentation
「モナドは象だ(Monads are Elephants)」日本語訳¶ この文章は、以下の記事の翻訳です。 Monads are Elephants: http://james-iry.blogspot.com/2007/09/monads-are-elephants-part-1.html http://james-iry.blogspot.com/2007/10/monads-are-elephants-part-2.html http://james-iry.blogspot.com/2007/10/monads-are-elephants-part-3.html http://james-iry.blogspot.com/2007/11/monads-are-elephants-part-4.html JAMES IRY:ONE DIV ZERO: http://james-iry
モナドはメタファーではない · eed3si9n
2011-05-28 Scala界の関数型プログラミング一派を代表する論客の一人、@djspiewak が 2010年に書いた “Monads Are Not Metaphors” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。 2010年12月27日 Daniel Spiewak 著 2011年5月29日 e.e d3si9n 訳 僕は今、約束を破るところだ。およそ三年前、僕は絶対にモナドの記事だけは書かないと自分に約束した。既にモナドに関する記事は有り余っている。記事の数が多すぎてその多さだけで多くの人は混乱している。しかも全員がモナドに対して異なる扱い方をしているため、モナドの概念を初めて学ぼうとする者は、ブリトー、宇宙服、象、砂漠のベドウィン (訳注: アラブ系遊牧民) の共通項を探す努力をするハメになっている。 僕は、この混乱した
QAで学ぶMonad - あどけない話
この記事は、Monad でつまづいた Haskeller のための Monad 再入門です。 Monadとは何ですか？ Monad とは、単なる型クラスの一つです。難しいという風評もありますが、それ以上でもそれ以下でもありません。 この型クラスのメソッドは、return と >>= です。 class Monad m where (>>=) :: m a -> (a -> m b) -> m b return :: a -> m a つまり、以下を満たす型の集合が Monad です。 m a で表現できるように一つの型変数を格納するコンテナ型 >>= と return を実装 return は新しいコンテナを作り、>>= は二つのコンテナを合成します。 Monad のインスタンスは失敗系と状態系に大別できます。以下に代表的なインスタンスを示します。 失敗系: Maybe、[] (リスト)
モナドって結局何なのよ? — join to Monad v0.1 documentation
モナドって結局何なのよ?¶ Haskell を勉強しようとすると必ず「モナド」ってのが出てきます。困ったものです。数学とか圏論とか関係があるらしくって、何が書いてあるんだか分からなくって嫌になってしまいます。でもね、Haskell って凄いらしいじゃないですか、格好良いらしいじゃないですか。ここはちょっとがんばって色々考えてみましょう。 そもそも Haskell って何なのよ?¶ 何なんでしょうね、Haskell って。コンピュータ言語らしいんです、あ、それは分かってると。良く挙げられる性質は次な感じ?: 関数型言語 強い型付け 遅延評価 参照透過 ここでちょっと型に関して見てみましょう。試しに Haskell の実装の 1 つである Hugs で 1 について考えてみます: $ hugs __ __ __ __ ____ ___ _____________________________
Applicativeのススメ - あどけない話
この記事の目的は、Applicative 信者による Applicative スタイルの布教です。 簡潔に結論を述べると、 foo = do a <- m1 b <- m2 return (f a b) のようなコードを書きたくなったら foo = f <$> m1 <*> m2 と書きましょうということ。 合い言葉は、「do と return をなくせ！」です。 FunctorとMonadの間 Functor を特殊化した型クラスがMonadで、Monadの方が強力です。なぜなら、メソッドが増えるからです。 Functorのメソッドはfmapです。fmapの別名を (<$>) といいます。(この記事では、(<$>) と liftM を同一視します。) そして、Monadのメソッドは、ご存知の通り (>>=) と return です。 FunctorとMonadの間にApplicative
Applicative よりも Monad の方が力が強い理由 - あどけない話
Applicative よりも Monad の方が力が強い理由を考えるためのメモ。これから議論するためのたたき台なので、そう思って読んで欲しい。 コンテナで包む return Monad とは、コンテナである。コンテナは、文脈を表す。たとえば、Maybe というコンテナは、失敗するかもしれない計算という文脈を表す。 通常の値や関数を文脈に入れるための API が return である。 return :: a -> ma コンテナ内での関数適用 <*> 以下のような型を持つ関数を考える。 f :: a -> b この関数を return を使って文脈の中に入れてやると、型は次のようになる。 return f :: m (a -> b) この関数を、コンテナ内にある値に適応するための API が (<*>) である。 (<*>) :: m (a -> b) -> m a -> m b コンテ
Monadとして抽象化すると何が嬉しいの？ - あどけない話
The Typeclassopediaには、以下のような文章があります。 結局、あらゆる誇大広告にもかかわらず、Monadは単なる型クラスに過ぎません。 また、The Trivial Monadでは、以下のように述べられています。 Haskell の Monad は型クラスの1つです。Haskell の型クラスは、複数の型で共通する API を定めます。だから、Monad という型クラスとは、型の集合に対する共通の API です。 共通の API とは、return と (>>=) のことです。 こう言われると、すぐに「その共通のAPIを使うと何が嬉しいの？」という疑問が湧くでしょう。もちろん、共通の API を使う嬉しさは、後から型を変えたときに、実装を変えなくてもいいことです。この記事では、その一例をお見せしましょう。 私が「Monad で実装してよかった」と感じたことがあるのはパーサ
jQueryはモナドだ - id:anatooのブログ
この記事はjQuery is a Monad | Important Shockという記事の勝手訳です。 追記1: bonotakeさんが補足記事を書いてくれています → JQueryがモナドかどうかとか - たけをの日記＠天竺から帰ってきたよ 追記2: hirataraさんが補足記事を書いてくれています → jQueryは本当にモナドだった - 北海道苫小牧市出身のPGが書くブログ Haskellプログラマーは誰しもがモナドに関する各々のチュートリアルを書くと言われる。というのも、一度モナドの定義とその可能性を理解すれば、モナド全体を囲む神秘性に挑戦して打ち破るのが容易になるからだ。門外漢からすれば、モナドはHaskellを真に理解することを妨げる不可解な障壁だ。モナドはとても不適当な名前で呪われていて、一風変わった文法を持ち、一度に何もかもやってしまう様に見える。しかしながら、その動き
モナドで悟りをひらきたいのなら - 図でわかる(?)モナド - Pixel Pedals of Tomakomai
圏論の最大の武器はダイアグラムなので、モナドで悟りをひらきたいのならダイアグラムを使えばいいんじゃないでしょうか。 ダイアグラムの書き方 例えば、「 f :: a -> b 」とか「length :: [a] -> Int」は以下のように書きます。型を点で、関数を矢印で書きます。 ダイアグラムの利点は、fやlengthの中身を忘れて簡略化することができることです。人間の脳ができることには限りがあるので、注目する情報が少ない方が理解しやすくなるってスンポーです。 なお、 合成 g . f は図示する時に順が逆になるので気をつけて下さい。これは、合成関数の適用が g ( f x ) と書けることに由来してます。まずfを適用し、次にgを適用するということです。 return と >>= の図示 今回のダイアグラムの約束として、元となる型(Bool, Char, Int 等)は最下段に書きます。そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
