Haskellとは (ハスケルとは) [単語記事]

Haskellとは、純粋関数型プログラミング言語の一種である。

概要

Haskellという言語名は論理学者Haskell B. Curryの名前が由来。純粋関数型言語の標準化を目的として制定されたといわれている。

静的型付けコンパイラ型言語で、型推論機能が利用できるため関数や変数の型宣言を省略することがある程度は可能である。プログラムの記述は、「等式の左辺は右辺の式へと変換できる」という関係性の定義を列挙していく形になる。

型付け以上に特筆すべきなのは純粋関数型言語ということである。Haskellにおける「関数」とは、数学における「関数」と同じく、引数の値が関数の返り値と一意に対応し不変であるものに限定される。関数が内部状態を持つことは許可されない。変数の初期値は再代入によって変更することはできない。このような制約を持つため、プログラムの各部分の実行順序を任意に選ぶことができ、今後並列演算への応用も期待できる。

Haskellにおいて、標準入出力を用いた処理など純粋な（数学における）関数表現では実現できない処理は「アクション」と呼ばれ「関数」とは区別しているが、両者を同一プログラム内で矛盾を起こさないように共存させる仕組みが提供されている。

変数・関数のスコープは、中括弧などコードブロックを囲むような記号は使わず、Pythonなどのようにソースコードのインデントの深さで表現される。

遅延評価を採用しており、無限リストを容易に扱うことができる。

開発環境

HaskellのためのフリーのコンパイラとしてはGHC(Glasgow Haskell Compiler)がデファクトスタンダード。他にはHugsなどがある。これらはEclipseからも利用することもできたが、現在はプラグインのEclipse FPと連携するパッケージが依存関係の変化に対応できず開発中止になっている。他の統合開発環境もパッケージの依存関係を解決できなくてインストールもままならないことが多く、フリーの開発環境はもっぱらテキストエディタが中心になる。

用途

間違いが発生しにくいとか、数学と相性が良いなどの理由からか、数字の計算に終始する金融投資関係での利用が多いといわれている。

参照透過性とGUIとは相性が悪いのでゲーム開発には適さないと考えられているが、Haskellで書かれた日本で有名なゲームにMonadiusというのがあり、開発が不可能ということはない。（GUIの処理ははOpenGLを利用したライブラリGLUTによるもの）

純粋関数型言語

Haskellは関数型言語の中でも、関数や再代入による状態変更を副作用として排除する道を選んだ純粋関数型言語である。

プログラミングスタイルとしては、その特性を活かして実行順序に関係なく、関係性の定義を宣言的に記述していくことで自動的に結果が導き出される宣言型プログラミングが推奨されている。従来のプログラミング言語とは全く違うその発想に、いわゆる命令型プログラミングに親しんできた人が接すると、拒絶反応を起こすか熱心な信奉者になるかに二極化するらしい。

「プログラミング言語が車だったら」のHaskellの項より選択抜粋

宇宙人の作った車と噂され、完全自動化を売りにしている。

Haskellの運転席にはハンドルもペダルも無く、代わりに運転装置と一体化したカーナビが取り付けられている。ドライバーは実際の運転操作をする必要がなく、このカーナビに目的地の定義を入力すれば、目的地までの運転が自動的になされる。

従来の自動運転システムでは、道路状況を判断できず公道を走ることは無理であったが、Haskellはこれを奇想天外な方法で解決した。Haskellには目的地として「青信号のときのみ進行し、飛び出す子供に注意しながら、ブロック塀にかすることなく入った我が家の車庫」が指定できるのである。

結局Haskellを試乗した多くのドライバーは「目的地の定義を考えるより自分で運転した方が手っ取り早い」と不満をもらすそうな。

モナド

先述のようにHaskellが属する純粋関数型言語というのは副作用を排除する道を選んだ言語である。副作用とは再代入のように状態を変更することである。それくらいならたいした問題ではないのだが、たとえば「画面に文字を表示する」という通常のプログラミング言語ではごく基本的なことに分類されることでも、Haskellでは画面の「状態の変更」であるとみなされる。

従って、純粋関数型言語であるためにはひたすら計算のみを行い結果の画面表示すら行わないという滑稽な状態にならざるをえない。もちろん、こんなことでは使い物にならないのでHaskellはモナドという仕組みを利用している。IOモナドというものがあり、副作用をIOモナドの処理に分離することにより、IOモナドの内部で純粋関数型言語であり続けるのである。

モナドはHaskellにとって副作用を起こすために必要なものではあったが、副作用を起こす以外にも様々な用途のモナドがあり、いわゆるぬるぽの対処をするMaybeモナドが代表的。さらにはListまでもがモナドとして提供されている。

擬人化するなら

Haskellを擬人化するなら、以下のような感じだろうか。

すべての家具が造り付けで固定された部屋の中に引きこもる潔癖症の数学少女。部屋から出ないので近眼のメガネ属性。外部とのやりとりは、壁にあいたIOモナドという小さな窓から行う。

期限が来てからでないと仕事を始めない彼女のことを怠け者と評する人もいるが、その評価は正格ではない。すべてのものが固定された彼女の部屋には予めすべてのものがあるべき場所に「ある」のだから、必要になったときに手を伸ばせば事足りるのだ。これを可能にするために常日頃から部屋を完璧に整理整頓している彼女は、怠け者ではなく地道な努力家なのである。だが引きこもりだ。

コード表記の例など

Hello worldの例

    main = putStrLn "Hello world!"

Haskellにおいて、文字列（String型）は文字（Char型）のリストとして扱う。リストは列挙した要素群を'['と']'で囲み、各要素の間は','で区切る。
文字列"Hello world!" は文字のリスト ['H', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd', '!'] と同じもの。

左辺の「目的とする結果」に代入するために右辺の「"Hello world!"と画面に表示された状態」を計算して作り出すと考えるなら、先述の「目的地として「青信号のときのみ進行し、飛び出す子供に注意しながら、ブロック塀にかすることなく入った我が家の車庫」が指定できる」ということの意味も見えてくるかもしれない。

Schemeにおけるリスト表現で、

(1 . (2 . (3 .(4 . ()))))

と　

(1  2  3  4)

が同一のリストのを表わすように、

Haskellでは、

1 : (2 : (3 : (4 : [])))　　　　※丸括弧を省略して、 1 : 2 : 3 : 4 : []　と書いてもよい

と　

[1, 2, 3, 4]

は同一のリストを表わす。　

Schemeのコード表記との比較例

　（記号「→」以降に式の評価結果を記す）

コードの説明	Haskell	Scheme
リストの先頭要素取り出し	head [1, 2, 3] → 1	(car '(1 2 3)) → 1
リストの先頭要素を除いた残り部分の取り出し	tail [1, 2, 3] → [2, 3]	(cdr '(1 2 3)) → '(2 3)
リストに先頭要素を追加	1 : [2, 3] → [1,2,3]	(cons 1 '(2 3)) → '(1 2 3)
空リスト判定	null [] → True	(null? '()) → #t
無名関数を使った演算	(\x y -> x + y) 1 2 → 3	((lambda (x y) (+ x y)) 1 2) → 3

自然数nの階乗 n ! を求めるコードの例

繰り返し処理は、他言語によくあるforループのようなものではなく再帰呼び出しや高階関数を使った手法で書くのがHaskellなど関数型言語の基本的な流儀。

-- 同名の関数定義を複数用意して、引数によるパターンマッチングを利用する例

factorial :: Int -> Int　　 -- 関数名はfactorialとし、引数は整数型の値を一つ取る、返り値も整数型の値
factorial 0 = 1                       -- 引数が0の場合、返り値は1とする
factorial n = n * factorial (n - 1)   -- 引数が0以外の場合は再帰呼び出しを使って返り値を求める

-- 条件式if使った例

factorial :: Int -> Int　　 
factorial n =
        if n == 0              -- Haskell2010の規定により then/else節のインデントは揃えなくてもよい
　　　　　　　　then 1                 　　　-- 引数nが0の場合、返り値は1とする
        　　　　else n * factorial (n - 1)     -- それ以外の場合は再帰呼び出しを使って返り値を求める

-- ガード節を使った例

factorial :: Int -> Int
factorial n
        | n == 0     = 1                          -- 引数nが0の場合、返り値は1とする
        | otherwise = n * factorial (n - 1)     -- それ以外の場合は再帰呼び出しを使って返り値を求める

-- case構文のパターンマッチングを使った例

factorial :: Int -> Int
factorial n = case n of 
                   0 -> 1                          -- 引数nが0の場合、返り値は1とする
                   _ -> n * factorial (n - 1)   -- それ以外の場合は再帰呼び出しを使って返り値を求める

同様の計算を再帰呼び出しを使わないで行うコードの例

-- 1からnまでの整数のリストを生成してその要素をすべてかけ算する例
-- 高階関数 foldl は、第2引数「1」と第3引数の整数リストの全要素を使って第1引数の「*」関数を適用
factorial :: Int -> Int
factorial n = foldl (*) 1 [1..n]   -- 具体的には、1 * (1 * 2 * 3  ....* n) の演算が行われる

参考外部リンク

The Haskell Programming Language: 本家サイト
Hoogle: 関数や演算子(googleでは記号は検索できない)の検索が可能。
Hackage: 公式パッケージリポジトリだが、原則として誰でも登録できるため品質の保証はない。
Stackage: 依存関係を解決したパッケージの組み合わせを公開している。

コラム: Hakellの闇に迫る

使わなかったものは理解不能と罵り、使用したものはすばらしいと絶賛する純粋関数型言語Haskell。Hakellユーザーからの肯定的な報告が相次ぐ中、あえてHaskellの闇に迫ってみようと思う。(不定期連載?全6回?)

1. 名前空間は犠牲になったのだ…

Haskellでは状態変更を禁止することにより、他のモジュールからの変更を考慮しなくていいように設計されている。逆に言うとオブジェクト指向などで強調されるカプセル化をしなくても、外部からの変更による問題は発生しにくいようにできているといえる。

この結果、Haskellでは内部構造を隠蔽しようという思想よりも、どこからでもアクセスできたほうが便利という思想が優先されている。代数データ型のレコード(他の言語では要素とかフィールドとかメンバーとかに相当)は、定義すれば無条件で外部から参照可能になる。変更はできないのでアクセスできても問題ないという点では正しいのだが、レコードの実装方法が変わった時は、内部構造が隠蔽されていないので外部に変更が及んでしまう。

実装変更の影響を受ける以上に外部から参照可能なことによる弊害があるのが、名前空間での衝突である。代数データ型のレコードへは、レコード名と同名の関数によってアクセスすることができる。従って、一つのファイルに同じ名前のレコードを持つ2つの代数データ型が存在すると、同じ名前の「関数」が2つ存在することになってしまう。これを避けるには一方のレコードの名前を変更するなどの対応方法が考えられるが、ライブラリなど他人が作ったものを利用する場合はそうも行かない。

となると、対応方法はモジュール名を付加して区別する(import qualified)くらいしかなくなるのだが、関数を使うたびにモジュール名を付加しないといけないとすると、その手間はかなりのものになる。モジュールの省略名を設定すれば、手間は軽減されるが、省略名の管理をしないとどのファイルでどの名前をどう省略したのかわからなくなってしまう。さらにファイルごとにモジュール名を付ける関数と付けない関数の区別など考え始めた日には、泥沼にはまってしまうのは想像に難くない。

名前空間は犠牲になったのだ…参照透過性の犠牲にな…

2. 日本語でおk

コンピューターもOSもプログラミング言語も多くはアメリカが発祥の地である。従って、文字については英語を前提としたASCIIなどの仕様策定がなされており、日本語などへの多言語対応については後付けになることが多い。特にコンピューターのリソース制限がきつかった昔のコンピューターやプログラミング言語にはこの傾向が顕著である。その結果、日本語を使用するためには文字化けなどと格闘する羽目に陥ることが日常茶飯事であった。

こういった反省を踏まえて、後発の製品では文字コードをUnicodeに統一するなどネイティブに多言語対応することが一般的になってきた。モダンな言語では日本語の文字列も英語の文字列も特に区別なく利用可能であることはごく当たり前になりつつある。

しかし、Haskellはそうではない。Unicodeは使えることは使えるのだが、ソースコード中では10進数コードポイント表記で書かなければならず、「ニコニコ大百科」は '\12491\12467\12491\12467\22823\30334\31185' となる。日本語でおkといわざるを得ない。

もちろんUnicodeのUTF-8をサポートするパッケージは存在するが、ネイティブ対応でない以上、いちいち気を配る必要があるという点には変わりがないのである。

3. 英語でおk

ところで　Haskellの演算子を見てくれ　こいつをどう思う？

>>=

すごく…モナドです…

>>=はHaskellを少しやると必ず出くわすことになるモナドに使うbindという演算子である。モナドについては簡単だという人からわけがわからないよという人まで評価が分かれるが、>>=という数学はもちろん他の言語でも見たことがない記号演算子とこれの糖衣構文であるdo記法あたりが最初の関門になる人も多いのではないかと思う。

この記号に慣れたらHaskellの演算子学習はおしまいかというとそうではない。HaskellはあのPerlでさえ尻尾を巻いて逃げ出しそうなほどの多彩な演算子があるのだ。その一部を(コンマスペース区切りで)ご紹介しよう。

<$>, <*>, >>^, <<<, .|., &&&, :<, |*><*|

前項で述べた日本語対応などもはやどうでもいい。英語でおkなので、せめて人間の言葉で書いてほしい…。そう思わずにはいられないのである。おまけにこういった変わった演算子は圏論に基づいているものが多く、抽象的で意味はおろか読み方すらわからないときている。

Haskell演算子の奥には深い闇が眠っているのだ…。

4. 右? 左? ご存知、ないのですか!?

たいていのプログラミング言語は、原則として数式と同じように左から順に計算する。演算子も一部の例外を除いて左結合(@という演算子についてa@b@cとあれば、(a@b)@cと解釈する)で、右結合の(a@b@cとあれば、a@(b@c)と解釈する)ものは直感的に理解できるもので、そもそも結合して用いることが少なかったりする。

Haskellでは関数適用は左結合であり、左から計算する原則は変わらないが、演算子には右結合のものが結構ある。具体的には、関数合成"."とリスト結合":", "++"、そしてLispの反省から括弧を減らすために導入された最低優先順位演算子"$"などが代表的である。厳密には演算子ではないが、関数型を表すときに用いる"->"も右結合である。

もちろんこれにはHaskellを知る方々から反論もあるだろう。f . g xは数学でも右から計算するし、数学同様に関数を左に引数を右に書く以上、f(g(h(x + y)))の括弧を減らそうと思えば、f $ g $ h $ x + yとして"$"は右結合としなければならないのは当然である。関数型を表す"->"も意味を考えれば右結合なのは自然である(リスト結合は…おや、誰か来たようだ)。しかし、言語仕様で括弧を極力減らした結果計算する順番を決めるヒントがなくなってしまったHaskellでは、関数合成などに高い頻度で現れる右結合に対応するため、演算子の優先順位だけでなく、右結合か左結合かの確実な知識が必要がないとコードを読むことすらできず、「ご存知、ないのですか!?」と言われてしまうことになる。これはコードを読む者にとって大きな負担となるのではないだろうか。

話は演算子の結合の話のとどまらない。"->"と"<-"の違いといわれて、すぐに答えられるだろうか。確かにこれくらいなら少しHaskellに慣れてくれば容易に答えられるだろう。ではこれはどうだろう。

">>="と"=<<", 左記と">=>"と"<=<", "<<<"と">>>", 左記と"^<<"と"<<^"と"^>>"と">>^"

ちなみに">>="は左結合だが"=<<"は右結合、他は向きが違ってもみんな右結合らしい。

おわかりいただけただろうか。Haskellの演算子は読みや意味が分かりにくい以外にも計算方向まで右だか左だか容易にはわからないようになっているのである。

使わなければどうということはない? そんなことはない。あなたが使わなかったとしても、他の人が使うことは止められない。そして、あなたが解説を求めて開いたページのサンプルコードにその記号が突如として現れる可能性は十分にあるのだ。

5. フフフ…モナドは四天王の中でも最弱…

6. ここからが本当の地獄だ

Haskellは静的型付け言語である。しかも、型安全が他の言語よりも徹底しており、一般的にはHaskellの長所とされている。しかしながら、このことが災いをもたらすこともあるのだ。

型安全が厳格であるがゆえに、あるライブラリの仕様がバージョンアップに伴って変更されると、型のちょっとした仕様変更によりそのライブラリに依存していたライブラリが使用不能になることが、稀によくある。

すると、その依存していたライブラリに依存していたライブラリが使用不能になり、というように連鎖反応的に広汎なライブラリが使用不可能になる。どの言語にもあることだが、Haskellは小さなライブラリが多数存在して複雑な依存関係を構成していることが多く、わざわざDependency Hell(依存関係地獄)という言葉まで用意されている。

型検査以外にも、ライブラリ開発者の数が少ないので一人だけで開発していたら独断で仕様変更ができてしまうとか、ユーザーも少ないので仕様変更しても苦情が来る量が少ないとか、他の言語に比べて互換性よりも仕様を洗練することを重視する文化があるとかなのかもしれないが、原因はともかく依存関係地獄が実在することだけは間違いない。

もっともHaskellもこの問題について手をこまねいて見ていたわけではない。cabalという標準のパッケージ管理コマンドがあり、依存関係をチェックしながらインストールしてくれる(なんとこのcabal、パッケージをインストールする機能はあるが、アンインストールする機能がない: cabal-devというものにはあるらしい)。cabalバージョン1.18以降ではサンドボックスが導入され、あるプログラムのためのパッケージバージョンの変更が別のプログラム開発に影響を及ぼさないようすることが可能になった。

また、依存関係が正しく解決されたライブラリバージョンの組み合わせを公開しているStackageというものも提供されるようになってきた。しかし、そのサポート期間は最長で1年と短く心許ない。

あなたは参照透過性にモナドや圏論など耳慣れない概念や見慣れない記号の地獄をくぐり抜けて、ようやくひと通りHaskellと標準ライブラリが使えるようになり、今度は本格的に外部ライブラリやフレームワークを使用したプログラミングに乗り出そうとしているところかもしれない。だが、これまであなたが地獄だと思ってきたものは、所詮はあなたの努力や能力が及んでいなかったということでに過ぎず、そこに理不尽さはない。しかし依存関係地獄は「正しく」ライブラリを利用する者にも等しく訪れる。ここからが本当の地獄だ。