logo
/
関数型プログラミング
2021-01-01

原理原則

圏論(category theory)

  • 数学には[圏論]という分野がある
  • この圏論を基盤としてモナド(Monad)モノイド(Monoido)の概念を取り入れたものが関数型プログラミング
    • →本当か?モナドとモノイドを無視することも出来るのでは?

モナド

30分でわかるJavaScriptプログラマのためのモナド入門 (何もわからん。。。)
  • モナドの例
    • jQueryの$().css().slideup()の様な記法はオブジェクトと関数のペアによるチェーンである
      • それぞれの関数はモナド
    • Array.reduce()もモナド
  • モナドの使い方
    • endofunctor(自己関手) : 構造を保ったまま同オブジェクトタイプを返すによってメソッドチェーンをつなげることが出来る
    • 通常の関数f(arg)はチェーンはつながらずf(f(f(arg)))obj.f()はチェーンがつながる obj.f().f().f()
      • Promiseによるコールバック地獄からの解消はコレによるもの
        • ※正確にはPromiseはモナドではない
          • Promiseは2を満たしていないので
  • モナドは以下3つの組み合わせである
      1. 自己函手(endofunctor)T:C→C
      1. 自然変換:η:IdC⇒T
      • C(Js圏)上に有る値をTにするη
      1. 自然変換 μ:T∘T⇒T
      • Tの重なりを取り除きTにする μ
  • 噛み砕くと、オブジェクトと関数の3つの組がモナド(endofunctor,unit,flat)
    • オブジェクト自身(と同じ構造を返す)mapメソッドを持つendofunctor特性のオブジェクト
    • unit関数
    • flat関数
  • チェーンでつなぐためにはこの3つが常に成り立つ必要がある→合ってる?
    • 1が無ければ次につながらない
    • 2が無ければ全ての値を扱えない
    • 3が無ければネストを扱えない

実際にどう使うのか (自分の解釈)

Javascriptで(独自に)モナドを取り入れるのはコストが高いのではないか

恒常モナド
class Identity {
		private value: number
		// endfunctor T:C→C
		constructor(value: number) {
				this.value = value;
		}
		// 自然変換:η:IdC⇒T
		bind(transform: Function) {
				return transform(this.value);
		};
		// 自然変換 μ: T∘T⇒T
		toString() {
				return this.value;
		}
}
var result = new Identity(5).bind((value: number) => new Identity(6).bind((value2: number) =>
		new Identity(value + value2)));

console.log(result.toString());
  • 自分自身を返すだけなのにこの有様である。(JavaScriptのモナド)
    • HaskellScalaの様に純粋関数型言語の糖衣構文があればよいのかもしれない
      • 余裕があれば触りたい

既にモナドとして扱えるものだけで良いのではないか

Arrayで扱えるmap,reduce,concatなどの関数を積極的につなげて行くという意識で十分ではないか

関数型プログラミング超入門に従う意識だけで良いのではないか)

  • フローを書くことがバグの原因である
  • 論理を関数としてそのままコードに書き写す

何が問題なのか

  • 関数型プログラミングの何が嬉しいのかが理解できない
  • 関数型プログラミングを深く理解するために「モナド」を理解する必要があるが、モナドはあまりに難しすぎる(と誤解してしまう)
    • 実際のところ「モナド」及び「圏論」の数学的な理解は必須ではない
      • 圏論を学ぼうとする必要はない
    • 巷に溢れる「比喩」は全てに当てはまらない上に、当てはまらない場合の理解を妨げる
    • 小学校の算数の四則演算の様に実例と実装を繰り返すことで自然と理解できる
      • →コレは本当かわからん
参考 読んだけどあまり良くなかった