Enumeratorは終了条件の検査からの解放だ - あどけない話
長年の疑問の答えが Enumerator だった。今日はそんなお話です。 findを実装する Real World Haskell の第9章に UNIX の find コマンドを作る例があります。最初は安直に実装してみましょう。まず、ディレクトリの内容を得る補助関数と、ディレクトリが辿れるか調べる補助関数を用意します。 getValidContents :: FilePath -> IO [String] getValidContents path = filter (`notElem` [".", "..", ".git", ".svn"]) <$> getDirectoryContents path isSearchableDir :: FilePath -> IO Bool isSearchableDir dir = (&&) <$> doesDirectoryExist dir <
使ってみよう Enumerator - あどけない話
Enumerator Package - Yet Another Iteratee Tutorialは、Iteratee: 列挙ベースのI/Oよりは分かりやすいのですが、やっぱりよく分かりません。なぜなら、僕は使い方を知りたいのに、作り方が書いてあるからです。そこで、Enumerator ライブラリの使い方を簡単に紹介します。 登場人物 Iteratee 入力をもらって計算をします run_ で実行します IO モナドが指定されていれば、副作用を起こせます オートマトンと考えると分かりやすいです Iteratee 同士は (>>=) で合成できます Iteratee >>= Iteratee → Iteratee Enumerator Iteratee と ($$) で合成することにより、新たな Iteratee になります Enumerator $$ Iteratee → Iterate
Haskell本の翻訳書 - あどけない話
Haskell本の翻訳が2冊、発売されます。 Real World Haskell オライリーの「Real World Haskell」が、同じ名前の「Real World Haskell」で、10月24日に発売される予定です。 分厚い本をよく訳したものだと感心します。訳を担当した山下さん、伊東さん、お疲れさまでした。 Programming in Haskell 「Programming in Haskell」の翻訳が「プログラミング Haskell」という書名でオーム社から発売されます。11月初旬を予定しています。訳したのは僕です。薄い本なので助かりました。:-) レビューして下さった方々に感謝します。
Haskellには副作用がないのか？ - あどけない話
ある人は、Haskell には副作用がないと言う。また、別のある人は Haskell には副作用があると言う。Haskell を学ぶ者にとって、こういった意見の食い違いが、Haskell を得体の知れない言語にし、学習の障壁となっているかもしれない。そこで、この記事では、なぜこのような意見の相違が生まれるのかについて説明したいと思う。 向心力か遠心力か？ 僕は高校三年になって受験勉強をするまで、物理の運動方程式が得体の知れないものに思えていた。 例として円運動を考えよう。ある説明では、円運動をしている物体には向心力が働いていると説明されている。また別の説明では、遠心力が働くと説明されている。一体、どういうことだろう？ 受験勉強でたくさんの問題を解いて、ようやく分かった。これらの説明はどちらも正しい。すなわち、観測者がどこにいるかによって、説明の仕方が異なるのだと。 観測者が円運動をする物体
クラスの必要性 - あどけない話
先週、輪講で「Real World Haskell」の6章を読みました。独自に定義した JSON の型 JValue を Int などへ変換する例題が載っています。このとき、独自に定義した JSON というクラスを使います。 僕は、いや、輪講に参加した全員は、この例題が何を言いたいのかさっぱり分かりませんでした。しかし今日、設定ファイルをどう扱うかを考えていて、ようやく理解できました。 たとえば、設定ファイルを読み込むプログラムを書くとします。設定ファイルは、こんな感じです。 Limit: 10 AllowRootUser: Yes この設定ファイルをパースする Haskell プログラムは、一つの型しか返せませんから、以下のように Int と Bool を包含する型を作ることになります。 data Config = CV_Int Int | CV_Bool Bool 解析結果は、こんな感
遅延評価とIO - あどけない話
僕は今、プログラマーとしての幸福感に満たされている。遅延評価を習得できたと思えるからだ。 遅延評価 なぜ関数プログラミングは重要かには、遅延評価の利点を以下のように説明している。 停止条件はループの本体とは切離すことができ、強力なモジュール化が可能となる。 例として載っている「ニュートン-ラプソン法による平方根」は、若干難しいので、簡単な別例を示そう。Haskell には、第一引数の数だけ、第二引数を繰り返す関数 replicate がある。 > replicate 3 'a' → "aaa" これを普通に実装するとこうなる。 replicate 0 c = [] replicate n c = c : replicate (n-1) c Haskell 以外で実装する場合、きっとループを使うだろう。ただ、ここでは再帰かループかは問題ではない。 問題は、「結果を作る仕事」と「終了条件を判断
UArray - あどけない話
同僚が Perl でのファイル処理で悩んでいました。あるデータの情報が、2 つのファイルに分かれて、順番を守って行ごとに格納されています。やりたいのは、2 つのファイルを同時に開き、どちらも最初の行から最後の行まで読みながら、データをつきあわせることです。ちなみにファイルの大きさは、それぞれ 750M と 500M です。 Perl から離れて久しい僕は、はじめの何が難しいのか分かりませんでした。しかし、よく考えてみると、2 つのファイルを同時に読み込む while の構文は存在しないことに気付きました。(嘘かもしれないので、Perl ハッカーのフォローを期待します。) 同僚には、こう言いました。「そんなの Haskell でやれば簡単だよ。ファイルは無限のリストに見える。無限リストは複数あってもいいし、map とか fold のために 1 つの無限リストにしたいなら zip すればいい。
HaskellとgetOpt - あどけない話
最近では、何かプログラムを書くときは、Haskell を使うようにしています。Haskell でスクリプトを書くと困ることの一つに、コマンドライン・オプションの処理があります。 IOモナド地獄 System モジュールで定義されている getArgs は IO [String] を返します。そこで、型が IO () である main などから以下のように使うことになります。 -- "-c" オプションを調べる import System main = do argv <- getArgs let cflag = "-c" `elem` argv -- ここに何か書く この方法には2つ問題があります。 main で getArgs を使うと、コマンドライン・オプションの処理結果(cflag など)を下位の関数にずっと渡していかないといけない コマンドライン・オプションの処理結果が必要な関数で
とりとめのないパーサー談義 - あどけない話
パーサーに関して、調べたことと疑問を書いておきます。パーサーに詳しい人に答えて頂けると、とても嬉しいです。 チョムスキー階層によれば、以下のような関係が成り立ちます。 正規文法 < 文脈自由文法 < 文脈依存文法 < 制限のない文法 それで、文脈自由文法の中は、こういう関係が成り立ちます。 LL法 < SL法 < LALR法 < LR法 < GLR法 GLR法は、文脈自由文法の全体を解析できる能力を持ちます。 疑問1) GLR法は、文脈依存文法(の一部)も解析できるのか？ LL(1) LL(1)に、収まっているのは XML や Lisp です。 LALR(1) LALR(1)に、収まっているのは、ほとんどのコンピュータ言語です。たとえば、C や Java。 GLR GLRに収まっているのは、C++ です。たとえば、D 言語の「テンプレート再訪」には、以下のように文脈がないと比較なのかテンプ
状態モナド遊び - あどけない話
状態をモナドで実現する方法を考えます。 リスト 例は簡単な方がいいので、データ構造として 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 風のリストに、要素の数を覚えさせておきたいとしましょう。もちろん、数えれば分りますが、数えなくても一瞬で分るようにしたいのです。
モナディック・パーサー - あどけない話
「ふつうのHaskellプログラミング」や 「構文解析結合子」の元ネタは、どうやら「Monadic parsing in Haskell」のようです。(さらに元ネタは Parsec ですかね。) このオリジナルは、MonadPlus の部分などが古くさいのですが、分りやすいです。というわけで、例題を Parsec 風にアレンジしつつ、勉強してみました。 四則演算式のパーサーを実現することを目標にします。 おまじない 最終的に以下のモジュールが必要になるので、import しておきます。 import Monad import Data.Char Parser の定義 Parser 型の定義はこうなります。 data Parser a = Parser (String -> [(a,String)]) 状態を表すために関数を使っている 関数を使うと状態が表現できることが分らない人は、先に「状
Haskellチュートリアル - あどけない話
先週、僭越ながら Haskell チュートリアルをやりました。その資料を公開します。 Haskell プログラミング 〜 純粋関数型言語への誘い〜
Haskell の 4 つの糊 - あどけない話
なぜ関数プログラミングは重要かでは、糊の重要さが強調されています。 問題を解くための部品プログラムを書くとき、その問題を部分問題に分割し、部分問題を解き、その解を合成する。元の問題を分割する方法は、部分解を張り合せる方法に直接依存する。それゆえに、概念的には問題をモジュール化する能力を高めるためにはそのプログラミング言語のなかで新たな糊の類を用意しなければならない。... 糊の重要性は、大工仕事との類比によって、正しく評価できる。椅子は、部分(座部、脚、背もたれなど)を作り、それらを正しくくっつけ合せることで容易に作ることができる。しかし、これはジョイントと木を張り合せるという能力に依存する。その能力がなければ、椅子を作る方法はひとつ木の塊からそれを彫り出す以外なく、非常に難しい作業になる。この例は、モジュール化の強大な力と正しい糊を持つことの重要性の両方を例示するものである。 僕が思うに
Haskell vs OOP - あどけない話
「Why Haskell matters?」(なぜ Haskell は重要か？)には、Haskell とオブジェクト指向プログラミングを比較した章があります。日本語訳が見当たらなかったので、必要な部分を訳してみます。 オブジェクト指向プログラミングの優れた利点は、データとそれに作用する関数を一つのオブジェクトにまとめられることではない。優れた利点、それは、(実装からインターフェイスを切り離せる)データのカプセル化と、(型の一群の振る舞いを同じようにする)多相性だ。しかしながら、データのカプセル化と多相性は、OOP の専売特許ではない！ いやぁ、心洗われる文章です。:-) データのカプセル化 Haskell でのデータのカプセル化は、それぞれのデータ型をそれぞれのモジュールで宣言し、そのモジュールからインターフェイスだけを公開することで実現できる。モジュール内部には、内部データに触れる関数群
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
