Haskellは勉強したけどモナドを本当に理解したって言えるのか自信がない… ＼そんな人向けの試験問題を作りました！／ これから実施する試験問題を、10問中8問正解すればあなたはHaskellのモナドを完全に理解しています。私が保証します！ それではさっそく〜〜 第一問 まずは緊張をほぐしましょう。 Haskellの Monad は○○○○である ○○○○に当てはまるのは以下の選択肢のうちどれでしょう？ 型 関数 型クラス 型シノニム 答え
「Haskellのモナド完全に理解した」試験問題
Haskellは勉強したけどモナドを本当に理解したって言えるのか自信がない… ＼そんな人向けの試験問題を作りました！／ これから実施する試験問題を、10問中8問正解すればあなたはHaskellのモナドを完全に理解しています。私が保証します！ それではさっそく〜〜 第一問 まずは緊張をほぐしましょう。 Haskellの Monad は○○○○である ○○○○に当てはまるのは以下の選択肢のうちどれでしょう？ 型 関数 型クラス 型シノニム 答え
CPSで実装したモナドは何故速いのか - Mizon Dev Diary
2014-01-20 CPSで実装したモナドは何故速いのかモナド変換子の速さを測ってみる - モナドとわたしとコモナドCPSでモナドを実装すると速くなるらしい。以前、その理由について考えてみたのだが、結論に達しなかった。そこで、続きを書く。まず、Twitterである方に教えていただいたのだが、CPSで実装したモナドは、非CPSで実装したモナドに比べて次の2点の理由により高速であるという。データの生成/分解が抑えられるから合成時に継続を破棄できるからどういうことなのだろうか。Maybeモナドを例として以上の2点を確認したい——。と、確認したかったのだが、検証したところ、1点目については結論を得たものの、2点目については「速くならない」という矛盾した結論が出てしまった。そこで、以上の1点目についてのみ検証した記録をつける。非CPS版Maybeモナドまず、非CPS版のMaybeモナドの定義は以下
Idris: A Language for Type-Driven Development
Idris: A Language for Type-Driven Development Idris is a programming language designed to encourage Type-Driven Development. In type-driven development, types are tools for constructing programs. We treat the type as the plan for a program, and use the compiler and type checker as our assistant, guiding us to a complete program that satisfies the type. The more expressive the type is that we give
Extensible Effects はモナド変換子に対する救世主になり得るか？
Extensible Effects はモナド変換子に対する救世主になり得るか？ konn-san.com Oleg, Sabry and Swords らによる Extensible Effects: An Alternative to Monad Transformers の論文を読んだメモ的な何かです。モナド変換子に関する簡単な現状確認から入ってはいますが、想定読者層は日常的にモナドやモナド変換子を用いたプログラムを書いている人達です。 どちらかというと自分向けのメモの性格が強いので、詳しい部分は論文を参照してみてください。 背景：モナド変換子とその問題 Haskell を中心に、関数型言語では副作用のある函数を合成するための手段としてモナドが広く用いられている。モナドは非常に強力な抽象化で、およそ副作用と呼べるものはモナドを使って定式化することが出来た。例えば、大域的な環境 r を
Functors, Applicatives, And Monads In Pictures - adit.io
Written April 17, 2013 updated: May 20, 2013 Here's a simple value: And we know how to apply a function to this value: Simple enough. Lets extend this by saying that any value can be in a context. For now you can think of a context as a box that you can put a value in: Now when you apply a function to this value, you'll get different results depending on the context. This is the idea that Functors
Free Monadを使ってみよう！ - Just $ A sandbox
続編：Free Monadを使ってみよう！(2) - みょんさんの。 Haskell楽しいです。 Haskellは純粋なのでとても大好きです。 ただ、Haskellでは副作用のあるように見える(手続きっぽい)書き方をしたくなる時がどうしてもありますので、そういうところでは手続きっぽい書き方をすることになります。 つまり、 A = do m <- BBB runSth m のようなコードを、特にフレームワークがしっかりした大規模なプログラムではしょっちゅう見ることになると思います。 はっきり言いますが、私はこれが嫌いです。 Haskell-likeじゃない！ なので、もっとHaskell-likeな書き方をしたいです*1。 はい、さて本題です。 Free Monadを使いましょう。 Free Monadモジュールの中ではFreeというそのままの名前のデータがあって、 data Free f
そろそろFreeモナドに関して一言いっとくか - モナドとわたしとコモナド
Freeモナドはすごい。 Haskellを書いていて、「特殊化された処理を記述するモナドが簡単に作れたら便利だろうなー」と思ったことはないだろうか？簡単に作れるのである、そう、Haskellならね。 これが、純粋なFreeモナドの定義である。 data Free f a = Pure a | Free (f (Free f a)) instance Functor f => Monad (Free f) where return = Pure Pure a >>= k = k a Free fm >>= k = Free (fmap (>>=k) fm) (Functor、Applicativeのインスタンス宣言は自明なので省略) 与えられたFunctorをお互いに埋め込み合っている、という漠然とした印象で、何が嬉しいのかよくわからないかもしれない。だが、この単純さこそFreeモナドの便利
Why free monads matter
Interpreters Good programmers decompose data from the interpreter that processes that data. Compilers exemplify this approach, where they will typically represent the source code as an abstract syntax tree, and then pass that tree to one of many possible interpreters. We benefit from decoupling the interpreter and the syntax tree, because then we can interpret the syntax tree in multiple ways. For
モナドとモナド変換子のイメージを描いてみた - melpon日記 - HaskellもC++もまともに扱えないへたれのページ
最初に言っておくと、モナドって何なの？っていう答えは一切ないです。 自分にとってモナドは「とりあえず型さえ合わせておけば何かいろいろしてくれる奴」程度としか認識できていないので、そんな説明できないです。 で、そんな自分が脳内でどういう風にイメージしてモナドやモナド変換子の混ざったコードを書いているかというのを図に表してみました。 ここら辺の話を図にした感じです。 モナドを触ってみた - melpon日記 - HaskellもC++もまともに扱えないへたれのページ モナド モナドには return 関数と >>= 関数があります。 こんなイメージです。下側の線が普通の関数型の世界、上側の線がモナドの世界です。 どちらもモナド側の出力しか無いので、どちらかの関数を使ったら、モナドから脱出することはできません。 ただ、>>= 関数の右側が点線の箱になっていることが分かるでしょうか。 ここには、太
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 コンテ
モナドのための圏論入門 - 針の上でprocessは幾つ踊れるか？
「モナドは自己関手圏のモノイド対象にすぎない」とワドラーはいったがその事を説明したいと思います。 次のものを説明します。 対象 射 結合則 恒等射 圏 関手 自然変換 圏の基礎 圏は以下のものから構成されます 射 対象 射はソースとターゲットを結ぶ矢印とされます XがソースYがターゲットの社は次の通りに記述されます。 射の結合 の二つの射が存在した場合結合する事ができます さらに以下の公理を満たす必要があります。 恒等射 結合則 恒等射 任意の対象Xに対して射 が存在し恒等射という、さらに任意の射に対して が成り立つ。 結合則 が成り立ちこれを結合則という。 関手 圏Cと圏Gが存在したとして、 CからGに対して 対象 射 を対応させるものである。この時関手は以下の性質を保っていなけばならない。 恒等射 射の合成 自然変換 圏Cと圏Dの間に、F、Gという関手が存在し、 FからGへ移す射 が存
The Typeclassopediaを訳しました, The Typeclassopedia - #3(2009-10-20)
■ [Haskell] The Typeclassopediaを訳しました The Monad.ReaderのIssue 13に掲載されたThe Typeclassopediaという記事が、Functor, Monad, Monoid, Applicative, Foldable, Traversable, Arrowといったような型クラスについて良くまとまっていて、そのあたりを知りたい時の取っ掛かりになりそうだったので翻訳してみました。 作者のBrent Yorgeyさんからも許可がいただけたので公開します。翻訳に慣れていないので変な日本語（特に専門用語の日本語訳はかなり怪しい）があったり、そもそも間違っていたりするかもしれませんので、何か見つけたらコメントを頂けると助かります。 ■ [Haskell] The Typeclassopedia by Brent Yorgey <first
参照透明な malloc は可能か (あるいは IO モナドについて) @ val it: α → α = fun
This entry was posted by Jun Mukai on Friday, 6 November, 2009 alohakun が次のようなことを書いていたのが面白かったので、今日ちょっと帰宅途中につらつら考えたんだけど、twitterでつぶやくには長すぎるのでちょっと書いてみることにします。 malloc() って副作用あるの ? もちろん内部的にはあるだろうけど、外部的な振る舞いだけを見ると、有効なメモリリージョンの先頭アドレスが返ってくるだけだから、観測できないと思うんだけど。 (http://twitter.com/alohakun/status/5433639881) Haskell で乱数作るときってどうやって参照透明にしてるんだ ? 乱数を直接作る関数は無くて、シードを元に、乱数の無限リストを作るとかなのかな。ならば、確保可能アドレスの無限リストを作れば、副作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Idrisのインストール - あむログ