Emacs Lisp のダメなところ - あどけない話
Emacs Lisp をこよなく愛する僕の目から、Emacs Lisp がダメだと思うところをまとめておきます。 文化的な問題 Emacs Lisper の多くは、Lisp が好きで使っているのではなく、Emacs が好きだからしかたなく使っているのでしょう。本当は C で書きたいのに、無理して Lisp を利用している感じです。 そのため、Emacs に付いてくる Emacs Lisp のコードは、Lisp らしくないものがほとんどです。単に C での発想を Lisp で表現しています。 これらのコードは、読みこなせないぐらい関数が大きく、副作用のある部分とない部分が分離されていません。また高階関数を用いて、データ構造を走査するコードと実際に仕事をするコードを分離するという意識も低いようです。 Google の MapReduceという論文のお陰で、Lisp の写像関数(map)と畳込み
GHC でスタックトレース - あどけない話
これまで GHC では、スタックトレースを取ることが有効なデバッグ方法ではなかった。 なぜなら遅延評価では、(再帰であってもなくても)末尾呼び出しは単なるジャンプになるから、スタックを使わないのである。スタックに戻る場所を積むのは、case と of の中で評価される式だけだ。(つまり、ここは正格に評価される。) この問題を解決するために GHC 7.4.2 から、わざわざスタックにログを残して、スタックトレースが取れるようになった。すなわち、最新の Haskell Platform をインストールしていれば、この機能を使えるということだ。 例として、以下のプログラムを考えよう。 module Main where main :: IO () main = print $ foo 3 + 1 foo :: Int -> Int foo x = x * 2 + bar x bar :: In
Haskell での例外処理 - あどけない話
リツイート数が30を超えたので、Haskell での例外処理について説明します。僕が思うに、Haskell での例外処理が分かりにくいのには、2つ理由があります。 ライブラリの混乱 パラダイムの違い 歴史的経緯により、Prelude にも Control.OldException にも Control.Exception にも catch があります。歴史的経緯を説明するのは面倒なので、これだけ覚えて下さい。「Control.Exception だけを使って、それ以外は忘れる」 そもそも純粋関数型で catch とか言われても分からないかもしれません。Haskell では、純粋な関数と IO とでは、例外処理の方法が異なります。命令的な catch などを使うのは IO です。純粋な関数には Maybe か、Either を使います。 純粋な関数 純粋な関数では、原則として例外を投げてはい
HaskellとテストとBDD - あどけない話
Haskellでの BDD を実践するとどうなるかを考えるためのメモ。 型 豊かなデータ型とセクシーな型システムを持つ Haskell では、型が以下のような意味を持つ。 仕様 保守性の向上 簡単なドキュメント 設計図 BDD では、テストの用語ではなく設計の用語を使ってテストを記述する。だから Haskell で、まず型を書く習慣があれば、ある意味 BDD を実践していると言える。この感覚は、他の言語のプログラマには分からないかもしれない。 fromList :: Ord a => [a] -> Set a fromList = undefined このコードはコンパイルを通過するので、型に関する誤りがないことを確かめられる。 僕はへなちょこなので、型を先に書くこともあれば、後から書くこともある。 単純なコードはさっさと実装したい 型は GHC に推測させて、ghc-mod で自動挿入す
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 など)を下位の関数にずっと渡していかないといけない コマンドライン・オプションの処理結果が必要な関数で
Haskellの開発ツール (2011年版) - あどけない話
Haskell開発に関係するツールをとりとめもなく列挙してみます。 エディタ/IDE 僕は、Emacs と haskell-mode と ghc-mod を組み合わせて使っています。haskell-mode は、行頭揃えの機能がしょぼいので、作り直したいと思っています。 IDE のバックエンドとしては、scionがありますが、使ったことがないので説明できません。(僕は ghc-mod で十分だと思っているので。) Leksah とか yi とかも聞きますが、使ったことがないので知りません。(いや、yi はちょっと使ったことがありますけど。) 興味のある人は自分で調べて下さい。 マニュアル 関数のマニュアルが読みたくなったら、GHCについてくるモジュールの一覧とhackageDBから探して下さい。ghc-mod を使っていれば、一発でブラウザに表示できます。 探すのが面倒なら、google
Haskellライブラリ入門 (2011年版) - あどけない話
この記事では、基本ライブラリである Prelude の関数をだいたい理解した人が、次に知るべきライブラリを紹介します。自由自在にリストを使いこなせ、正規表現がなくてもプログラミングができるんだなと実感した人を対象にしています。 この記事のテーマは、脱リストです。リストはとても柔軟ですが、リストで表現されている文字列は、メモリーをたくさん消費しますし、なにより遅いのです。実用的なプログラムを書くためには、必要に応じて適切なデータ構造を使う必要があります。 containers containersは、文字通りコンテナ型をいくつか集めたパッケージです。ハッシュの代替品やキューとして使えます。連想リストを使っているところは、すべて Data.Map などで置き換えることをお勧めします。 containers に入っているモジュールはすべて眺めましょう。そして、実装も読んでみましょう。(プログラミ
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、[] (リスト)
Haskellの神話 - あどけない話
Haskell の優雅さを示すためによく使われるコードは、優雅さと分かりやすさだけに特化しており、現実的には遅いことが多い。書き手は他に効率のよい実装があることを知っているのだけれど、読み手はそうではないから、後で効率が悪いと気づいて愕然とするみたいだ。 この記事では、神話になっている例を3つ取り上げ、効率のよい実装と合わせて紹介する。その 3 つの例とは、以下の通り。 フィボナッチ数 素数生成 ソート フィボナッチ数 遅延評価を活かした優雅なフィボナッチ数の実装は、以下の通り。 fib n = fibs !! n fibs = 0 : 1 : zipWith (+) fibs (tail fibs) Haskellの「fib = 1:1:zipWith (+) fib (tail fib)」はとても遅いにも書かれているように、この実装は遅い。 その理由は、(+) の計算が遅延し、その待機
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
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
Haskell演習の草稿 - あどけない話
プログラミングの経験はあるが、Haskell は使ったことがない人に、2時間ぐらいで Haskell のよさを教える演習のネタを考える。 Haskell の代表的な利点といえば、 型による厳密なプログラミング QuickCheck によるテストケースの自動生成 Persec によるパーサーの作成 だ。今回は、パーサーの作成は諦めて、上2つについて教えてみる。 リストの探索プログラム まず、連想リストを探索するプログラムを書く。標準では lookup という関数が用意されているが、これを search という名前で再発明する。オーダーは O(n)。 まず、型を考える。 search :: Eq k => k -> [(k,v)] -> Maybe v search = undefined 次に、実装を考える。 search :: Eq k => k -> [(k,v)] -> Maybe v
リストは非決定性のモナド - あどけない話
Haskell のリストはモナドであり、それは非決定性の文脈を表すと言われます。しかし、そのことを扱った例題は少なくて、しかもイマイチでした。そこで、Scheme で書かれたよい例題を Haskell で書き直してみました。 「On Lisp」の「非決定性」の章では、謎めいた関数 choose と fail が出てきます。こんな難しい話をしなくても、Haskell では単に全探索することで非決定性を実現できます。なぜなら、Haskell の評価戦略は遅延評価なので、答えの先頭しか要求しなければ、残りの答えは探さないからです。 というわけで、Haskell で非決定性の問題を解くことは、リストを使って普通にプログラミングすることとなんら変わりません。 三平方の定理 「もうひとつの Scheme 入門」に載っている三平方の定理に関する問題を解いてみましょう。 x = [1,2,3,4,5],
とりあえず僕のスライドを公開 - あどけない話
Haskellers Meeting 2010 Spring で発表した僕のスライドを以下のように公開しました。 Haskell で Web サーバーを実装してみました Experience on implementing a Web server in Haskell
Haskellと副作用 - あどけない話
よく、Haskellには副作用がないと言われるが、それは間違いだ。確かに、Haskell には状態の変化（あるいは再代入）という副作用はない。しかし、入出力という副作用はある。この記事では、Haskell の副作用に対して、命令型プログラマーにすっきりと理解できる説明を試みたいと思う。 間違った方向への第一歩 Haskell の副作用に関する典型的な説明は、こんな感じだ。 Haskell にはあらゆるレベルで副作用がない。そのため、遅延評価が可能になる。遅延評価では、コードが記述順に実行／評価されるとは限らないので、入出力と相性が悪い。そこで、IO モナドが導入されている。IO モナドのおかげで、入出力に関するコードは記述順に実行され、外界に作用できる。 この説明を聞いて理解しろという方が無理である。説明が苦しい最大の理由は、Haskell にはあらゆるレベルで副作用がないと、間違った一歩
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://kazu-yamamoto.hatenablog.jp/entry/20080401/1207032525