私が関数型プログラミングについて度々耳にするようになったのは、数カ月前からです。でも当時は、それが何なのか見当もつかず、単なるバズワードだと思っていました。皆さんの中にも、そのような方は多いでしょう。それ以来、私は関数型プログラミングについて深く学び、この言葉を日々聞いてはいるものの内容を理解していない初心者の方のために、分かりやすく説明しようと思い立ちました。

関数型プログラミング言語の話になると、「 Haskell と Lisp は どちらが優れているのか 」という 議論 が 白熱する 傾向にあります。HaskellとLispはどちらも関数型言語ですが、実際には大きな違いがあって、それぞれに長所と短所があります。その具体的な内容については、この記事を読み終える頃には深く理解していただけると思います。この2つの言語には、それぞれから派生した言語があります。その中で恐らく皆さんが耳にしたことがあるのが、 Elm と ClojureScript でしょう。どちらもコンパイルするとJavaScriptになります。これらの言語の詳細については、後ほど説明しましょう。 この記事の一番の目的は、関数型プログラミングの主要概念とパターンをしっかりとお伝えすることです。

この先は複雑な内容になりますので、お手元にコーヒーなどを用意しておいてください。

純粋関数

関数型プログラミングの要となるのが、 ラムダ計算 というロジックを記述するための計算体系です。数学者はよくデータ変換という形でプログラムを記述して、主要概念である 純粋関数 に帰着させます。純粋関数には 副作用 がありません。つまり、 純粋関数は入力値にのみ依存するので、入力値が同じであれば必ず結果は等しくなります。 では以下の例を見てみましょう。

// pure function
const add10 = (a) => a + 10
// impure function due to external non-constants
let x = 10
const addx = (a) => a + x
// also impure due to side-effect
const setx = (v) => x = v

この非純粋関数は間接的に x に依存するので、 ｘ を変化させると入力値が同じであっても addx の出力結果は変わります。これにより、コンパイル時の静的解析やプログラム最適化がしづらくなります。しかし実際には、JavaScript開発者が プログラミングをする際の認知的負荷は、純粋関数により抑制されます。 純粋関数の作成時は関数の中身だけに専念すればよいので、 addx 関数を作成しながら、もし何かの要因で x が変化したら…、などと外部要因を気にする必要はありません。

関数の合成

純粋関数の利点の1つは、 合成して 新しい関数を作成できることです。 compose は、ラムダ計算でプログラムを記述する際に使う特別な演算子の1つです。composeは2つの関数を引数に取り、それらを” 合成して “新しい関数を作ります。では以下を見てみましょう。

const add1 = (a) => a + 1
const times2 = (a) => a * 2
const compose = (a, b) => (c) => a(b(c))
const add1OfTimes2 = compose(add1, times2)
add1OfTimes2(5) // => 11

compose は、前置詞の”of（～について）”に似ています。引数の順番と計算方法を見ると、「2倍した値 について 1を加算する」というように2つ目の関数を先に計算しているのが分かります。この compose と逆の動きをするのがUNIXでおなじみの pipe で、こちらの方が直感的に理解しやすいでしょう。 pipe は以下のように関数の配列を引数に取ることもできます。

const pipe = (fns) => (x) => fns.reduce((v, f) => f(v), x)
const times2add1 = pipe([times2, add1])
times2add1(5) // => 11

関数の合成によって小さな関数を統合（合成）すれば、より複雑なデータ変換を実装できます。関数を合成して、データを分かりやすく簡潔に処理する方法については、 こちらの記事 の例をぜひご覧ください。

実際に、 合成はオブジェクト指向の継承に 勝る 代替手段 だと言えます。信じられないという方もいると思うので、実例を紹介しましょう。以下のように、ユーザへのあいさつ文を作成する状況を想定してみてください。

const greeting = (name) => `Hello ${name}`

とてもシンプルな純粋関数ですね。ではここでプロジェクトマネージャから、ユーザのデータをさらに渡され、名前の前に敬称を付けるよう言われたとしましょう。そして以下のコードを書いたとします。

const greeting = (name, male=false, female=false) =>
  `Hello ${male ? ‘Mr. ‘ : female ? ‘Ms. ‘ : ‘’} ${name}`

それほどひどいコードではありません。でも、「Dr.」や「Sir」など他の分類についても、どんどんブール値を追加していったらどうなるでしょう？　名前の後ろに「MD」や「PhD」も付けて、「こんにちは」の代わりに「やあ」とカジュアルなあいさつを表示しようとしたら、一体どうなると思いますか？　もう、手に負えなくなるはずです。

このようにブール値を関数に追加するのは、厳密にはオブジェクト指向の継承ではありません。とはいえ、これはオブジェクト内の属性やメソッドが、継承時に拡張またはオーバーライドされるケースと似ています。ではブール値を追加する代わりに、関数を合成してみましょう。

const formalGreeting = (name) => `Hello ${name}`
const casualGreeting = (name) => `Sup ${name}`
const male = (name) => `Mr. ${name}`
const female = (name) => `Mrs. ${name}`
const doctor = (name) => `Dr. ${name}`
const phd = (name) => `${name} PhD`
const md = (name) => `${name} M.D.`
formalGreeting(male(phd("Chet"))) // => "Hello Mr. Chet PhD"

こちらの方がはるかに扱いやすく、判別しやすいですね。各関数は 1つの処理だけ を行うので、関数の合成は簡単です。では全てのケースを扱うために、便利なpipe関数を使ってみましょう。

const identity = (x) => x
const greet = (name, options) => {
  return pipe([
    // greeting    
    options.formal ? formalGreeting :
    casualGreeting,
    // prefix
    options.doctor ? doctor :
    options.male ? male :
    options.female ? female :
    identity,
    // suffix
    options.phd ? phd :
    options.md ?md :
    identity
  ])(name)
}

純粋関数や関数の合成のもう1つの利点は、エラーを追いやすいという点です。エラーが発生した時にはいつでも、バグの発生源まで、全ての関数のスタックトレースを確認することができるはずです。オブジェクト指向プログラミングでは、バグを引き起こす残りのオブジェクトの状態が分かるというわけではないため、しばしば混乱を引き起こします。

関数のカリー化

関数のカリー化は、Haskell を開発したのと同じ人物によって考案されました。その人物とは Haskell Curry です（訂正：Haskell Curryの名にちなんで名づけられました）。関数のカリー化は、少ない引数で関数を呼び出した場合、残りの引数を取るために、その呼び出された関数が別の関数を返すような関数にすることを指します。詳細については、 この記事で分かりやすく説明 されています。ただし、ここでは Ramda.js curry function. を使った簡単な例が紹介されています。

以下の例では、2つの引数を取るカリー化された関数”add”を生成しました。引数を1つ渡す場合、1つの引数だけを取る”add1″と名付けた部分的に適用された関数が得られます。

const add = R.curry((a, b) => a + b)
add(1, 2) // => 3
const add1 = add(1)
add1(2) // => 3
add1(10) // => 11

Haskellでは全ての関数が自動的にカリー化されます。任意やデフォルトの引数は存在しません。

実際、 map関数や合成関数、pipe関数 を使用する場合、関数のカリー化はとても便利です。以下がその例です。

const users = [{name: 'chet', age:25}, {name:'joe', age:24}]
R.pipe(
  R.sortBy(R.prop('age')), // sort user by the age property
  R.map(R.prop('name')),   // get each name property
  R.join(', '),            // join the names with a comma
)(users)
// => "joe, chet"

上記を見るとデータ処理がとても宣言的なのが分かります。まるでコメントのようにコードが読めることに気づくでしょう。

モナドと関手と装飾的な言語

モナド や 関手 は、すでに知っている関数に対する装飾的な言葉です。もっとしっかり理解したい場合は、 こちらの記事を読むこと を強くお勧めします。分かりやすい図を使って、よく説明されています。実際にはここまで複雑ではありません。

// monad
list = [-1,0,1]
list.map(inc) // => [0,1,2]
list.map(isZero) // => [false, true, false]

モナドや関手について重要なことは、数学者たちが圏論でこの構造を研究しているということです。これによって、プログラムを理解するためのフレームワークだけでなく、コンパイルする時の静的解析やコードの最適化に使うことのできる 代数定理や証明 をもたらしてくれるのです。これがHaskell の主な利点でもあります。 Glasgow Haskell コンパイラ は人類が作りだした傑作です。

圏論で表されるあらゆる定理や恒等式があります。以下は簡単な恒等式の例です。

list.map(inc).map(isZero) // => [true, false, false]
list.map(compose(isZero, inc)) // => [true, false, false]

mapをコンパイルする場合、効果的なWhileループを用います。一般的に、 O(n) operation (線形時間) ですが、リストで次のアイテムに対するポインタの増加に関連したオーバーヘッドがまだ存在します。そこで2番目の場合では、実に2倍の効率で、コンパイル時にHaskellがコード処理を明らかに速くするための変換があります。これにはちょっとしたイカすコツがあるのですが、後で説明します。

もう少しモナドについて触れると、 Maybe モナドと呼ばれる面白いモナドがあります（Swiftでは、たまに Option や Optional などと呼ばれています）。Haskellでは、 null や undefined といった概念がありません。そこで潜在的に null であることを表現する場合は、Haskellコンパイラが何をすべきか分かるように、モナドでラップする必要があります。

Maybe モナドは Nothing か Just something かのどちらかの 共用体型 です。Haskellでは Maybe を以下のように定義付けできます。

type Maybe = Nothing | Just x

小文字のxはあらゆる型を示します。

モナドであれば、含まれている値を変えるのに Maybe 上で .map() を使えます。 Maybe 上でmapした場合、もしそれが Just 型だったら、関数に値を入れ、新しい値とともに新しい Just を返します。また Maybe モナドが Nothing 型だったら、 Nothing を返します。Haskellでは構文はほとんど無駄がなく、パターンマッチングを使えますが、JavaScriptでは Maybe モナドを使う場合は次のようにする必要があるでしょう。

const x = Maybe.Just(10)
const n = x.map(inc)
n.isJust() // true
n.value() // 11
const x= Maybe.Nothing
const n = x.map(inc) // no error!
n.isNothing // true

このモナドはJavaScriptのコードに関して、あまり役に立たないように思われるかもしれません。しかし、モナドがどうしてHaskellでそれほど有益なのかを見ておくのは興味深いことです。 Haskellは、プログラムにおける全てのエッジケースで行うべきことを定義するよう要求します。もし定義しなければ、コンパイルはできません。 HTTPのリクエストを実行する時には、リクエストが失敗して何も返ってこないことがあるかもしれないので、 Maybe 型が返されます。もしリクエストが失敗するような事例を扱わなければ、プログラムはコンパイルできません。このことは基本的に、ランタイムエラーが検出できないことを意味します。おそらく、プログラムは間違った動きをするでしょう。しかし、JavaScriptで実行されがちなことと同じように、ただ魔法のように実行を中断することもありません。

これはElmを使う上での重要なセールスポイントです。タイプシステムとコンパイラは、プログラムがランタイムエラーを発生させずに動くことを、強要するのです。

モナドと代数構造に照らしてコードを考えることは、問題を構造化された方法で定義し理解するのに役立つでしょう。例えば Maybe の面白い拡張は、エラーハンドリングのための 鉄道指向プログラミング の概念です。また 注目すべき動向 は非同期イベントをうまく扱うモナドなのです。

あらゆる種類のモナドや多くの用語を、私自身も完全に理解しているわけではありません。しかし、すべての専門用語の不変性を保つために、 Fantasy Land や 型クラスペディア といった仕様書があります。その仕様書は、慣用的で機能的なコードを書くことを目的として、圏論における異なった概念を統一しようとしています。

参照の透明性と不変性

このような圏論とラムダ計算式の全てを利用するもう一つの意味合いは、 参照の透明性 です。数学者にとって、 同一の2つの事柄が、お互いに等しくはない時 、論理プログラムを解析するのはとても大変です。これはJavaScriptのいたるところに存在する問題です。

{} == {} // false
[] == [] // false
[1,2] == [1,2] // false

さて、参照の透明性の無い世界で数学を学ばなければならないと想像してください。「空配列は空配列と同じものである」という証明を書くことはできないでしょう。重要視すべきことは、配列の 値 であって、配列の参照ポインタではありません。そこで関数型プログラミング言語では値を比較するために、deep-equalを用います。しかし、これはとても効率が良いというわけではありません。そこには、参照を利用するこの比較をより速くするための巧妙なトリックがあります。

先に進む前に、1つはっきりさせておきたいことがあります。関数型プログラミングにおいて、その参照を変えることなく、変数を変えることはできません。そうしなければ、変更処理を実行する関数は非純粋関数になるでしょう。このように、「2つの変数が参照に関して等しいならば、その値も同様に等しくなければならない」ということが保証できます。また、適切な場所で変数の変更処理をすることができないので、変数を変換したいと思うたびに、新しい記憶場所に値をコピーしなければなりません。これは途方もないパフォーマンスの損失で、 ガベージスラッシング という結果を招きます。そしてその解決策が 永続データ構造 なのです。

永続データ構造の簡単な例は、 連結リスト です。リストの最後まで参照し続けるだけだと思ってください。2つのリストを比較する場合は、その最後が参照に関して等しいかどうかを最初に見ることができます。もし2つが等しいならば、これは素晴らしい近道です。この確認が終われば、2つのリストは同じものです。もしそうでなければ、各リストのアイテムについてくまなく、繰り返し値が同じかどうかの確認を始めなければいけません。このリストに効率よく新しい値を加えるには、メモリの新しいセットにそのリストを丸ごとコピーする代わりに、新しいノードのリンクを単に追加して、新しい先端の参照を追跡すればいいのです。このことにより、新しいデータ構造の中の以前のデータ構造と、新しい参照とを構造的に共有して、以前のデータ構造も持ち続けることができます。このような不変データを変換させるためのデータ構造を一般化したものを ハッシュ配列マップトライ （HAMT）と呼んでいます。これはまさに Immutable.js や Mori.js で行うことです。ClojureScriptとHaskellではコンパイラに組み込み済みですが、もうElmに実装されたどうかについては確信が持てません。

不変データ構造を用いれば、パフォーマンスの向上が得られ、整合性の維持に役立ちます。 React は「 propsとstate は常に不変なので、不必要なレンダリングをするより先に、以前の propsとstate が参照に関して次の propsとstate と等しいかどうかという照合が効率的に可能である」と仮定しています。また他の状況では、不変データを用いることで、知らないうちに値が変わらないことを保証するのに単純に役立ちます。