Haskell 単語

49件

ハスケル

9.9千文字の記事
  • twitter
  • facebook
  • はてな
  • LINE

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

概要

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

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

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

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

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

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

実装と開発環境

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

マイナー実装だが、Java仮想マシン向けにFregeexitEtaexitという実装が存在する。前者はJavaコードトランスパイルされ、後者Java仮想マシン用中間バイトコードコンパイルされる。両者ともJavaライブラリが利用可だが、Javaから持ち込まれたクラスの扱い方は異なっている。

用途

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

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

純粋関数型言語

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

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

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

  • 宇宙人の作ったと噂され、全自動化を売りにしている。
  • 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!"と画面に表示された状態を計算して作り出す関数」という「値」(Haskellは関数も数値と同じく参照透過な値)である。

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) の演算が行われる

関連動画

関連商品

下記の2冊は原書(英語)がwebで読めるらしい。

下記左上は上記左の翻訳書。ちなみに「すごいH本」といういかがわしい通り名がついているが、原題を見ればわかるように普通の本である。

関連コミュニティ

関連項目

参考外部リンク

コラム: Hakellの闇に迫る

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

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

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

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

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

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

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

2. 日本語でおk

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

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

しかし、Haskellはそうではない。Unicodeが使えるところも多いのだが、show, printなど一部の基礎的関数では10進数コードポイント表記が使われており、「ニコニコ大百科」は '\12491\12467\12491\12467\22823\30334\31185' となる。日本語でおkといわざるを得ない。

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

3. 英語でおk

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

>>=

すごく…モナドです…

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

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

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

前項で述べた日本語対応などもはやどうでもいい英語でお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. フフフ…モナドは四天王の中でも最弱…

以下は、2014年末の時点でのWikipediaでのモナド(プログラミング)の記事の冒頭である。

計算機科学におけるモナド英: Monad)とは、計算機科学者のEugenio Moggiによって提案されたモジュール性を持たせた表示的意味論の組みを言う。プログラムとはクライスリ圏の射である(a program is an arrow of a Kleisli category)、という要請から合成規則としてクライリトリプル(Kleisli triple)というモナドと等価なものが用いられる。システムへの適用であるプログラミング言語のHaskellで用いられるものがよく知られている。

!? おまえは何を言っているんだ? まるで意味がわからんぞ!

それでもGoogle先生なら…Google先生ならきっと何とかしてくれる…わからない単語を片っ端から調べれば…そう、まずはこのクライスリ圏から…

と思ってクライスリ圏とは何かを調べようとするわけだが、Google先生ですらクライスリ圏のことはよく知らないらしい。Wikipdiaにも2014年12月1日までは項すらなかった。2016年10月現在、記述はあるもののやはり数学者にしか分かりそうにない記述のままである。

2016年10月現在インターネット上において様々な人によってモナドに関する解説が試みられており、中途半端な理解に基づくものや、途中で挫折してしまっているものも見かけるが、上記2014年以前の状態にべたらかなり改善されたと言える。

しかし、Haskellの圏論の話はモナドでおしまいではない。アプリティヴ、ファンクター、アローモナド変換子と、まだまだ先があるのである。残念ながら、ほとんどの記事がモナド解説で力尽きており、こういったところに関しては解説が少ないか、あっても上級者向けの内容であったりする。

これらの概念モナドより難しいかといえば、必ずしもそうではないかもしれない。だが、ゲームボスキャラを思い浮かべてほしい。十分に攻略情報が与えられて最強隠しボスに挑むよりも、攻略情報なしで初見中ボスに挑む方がはるかに難しい場合があるのではないだろうか。

そういう意味では、解説が充実しているモナドがHaskellに出てくる圏論用語の中で最弱であると言っても過言ではないのである。

ただ、モナド解説2015年以降、1年くらいの間にだいぶ充実してきたことを考えると、他の用語の解説も何年か待っていたら時間が解決してくれるのかもしれない。Google先生次回作にご期待下さい

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

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

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

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

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

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

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

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

この記事を編集する
流行語100

掲示板

おすすめトレンド

ニコニ広告で宣伝された記事

記事と一緒に動画もおすすめ!
もっと見る

急上昇ワード改

最終更新:2024/11/30(土) 00:00

ほめられた記事

最終更新:2024/11/29(金) 23:00

ウォッチリストに追加しました!

すでにウォッチリストに
入っています。

OK

追加に失敗しました。

OK

追加にはログインが必要です。

           

ほめた!

すでにほめています。

すでにほめています。

ほめるを取消しました。

OK

ほめるに失敗しました。

OK

ほめるの取消しに失敗しました。

OK

ほめるにはログインが必要です。

タグ編集にはログインが必要です。

タグ編集には利用規約の同意が必要です。

TOP