🚂 👩🏼‍🔬 🤰🏼 ScalaのFP：ファンクターとは？ 🃏 🍓 🚁

関数型プログラミングの研究を開始する専門家は、用語のあいまいさと複雑さの両方に直面し、「深刻な数学」への言及を常に受けています。

この記事では、カテゴリ理論とScalaの難解な言語メカニズムを使用せずに、2つの重要な概念を検討します。

共変ファンクター
コントラバリアントファンクター

含めることができるカテゴリ構造のセット全体を理解するための出発点です

指数（不変）ファン クター 、 BiFunctor 、 ProFunctor
Applicative Functor 、 Arrow 、 Monad / Co-Monad
モナド変換器 、 クライスリ 、 自然変換

カテゴリー用語の起源について説明し、カテゴリー抽象化の実装における言語メカニズムの役割を示し、Scala標準ライブラリーからのいくつかの共変（ Option 、 Try 、 Future 、 List 、 Parser ）および反変（ファンディング、 Equiv ）ファンクターを検討します。

「カテゴリシリーズ」の最初の記事：

ScalaのFP：ファンクターとは？
ScalaのFP：Invariant Functor

Scala、数学、関数型プログラミングの世界をさらに詳しく知りたい場合は、 Scala for Java Developersオンラインコースをお試しください（ビデオ+テスト、価格のわずか25％！）。

抽象化の言語メカニズムについて

基本的に新しいプログラミング言語への没入には、以下の学習が含まれます。

新しいタイプの抽象化のための言語メカニズム。
これらのタイプの抽象化が使用される典型的なイディオム/パターン。

例：OOPは、クラス、インスタンス、継承、ポリモーフィズム、カプセル化、委任、...およびGoF設計パターンの概念を調査します。この設計パターンでは、このようなさまざまな抽象化メカニズムがすべて使用されます。

私の意見では、移行Java => Scalaの主な問題は、プログラマーが新しい抽象化メカニズム（より高い種類のジェネリック、パス依存型、型クラス、マクロなど）を学習しないことです。。

そして、「抽象化の対象」（ファンクター、モナド、モノイド、従属型など）の話が始まるとすぐに、現代数学（カテゴリー理論、抽象代数、数理論理学）の理論家が現れ、「ボードからすべてのピースをひっくり返します。」プログラマーの観点からは、数学者はしばしば、カテゴリーの到来の証人派/型のホモトピー理論/構成の計算の狂信者のように振る舞います：「私たちの言語で」と言ってプログラミングの分野から具体的な例を与えるのではなく、彼らは抽象数学の観点から注いで、彼らの聖人を参照しますテキスト

この記事では、ファンクター（共変および反変）は、カテゴリー理論に頼らずに基本的なScalaの特徴のみに基づいて分析されます。 より高い種類の 型クラスとジェネリックは使用されません（たとえば、 Scalazライブラリの作成者は、 scala.scalaz.Functor + scala.scalaz.Contravariant 、Cats： scala.cats.Functor + cats.functor.Contravariant 、Algebird： com。 twitter.algebird.Functor ）。多くの場合、イディオムの共変ファンクターと反変ファンクターに対応する型の名前では、省略名（ファンクターと反変）が使用されることに注意してください。

一般的に、Scalaの関数型プログラミング（L2〜L3レベル）は、Javaに対していくつかの方向のオフセットです（3つ参照）。さらに、オフセットは4つの「コンポーネント」によって同時に特徴付けられます。

新しいプログラミングテンプレート/イディオム/真珠。
これらのイディオムを実装するためのScalaの新しい言語エンジン。
言語メカニズムに基づくイディオムの実装を備えた新しいScalaライブラリ。
イディオムの重要なアイデアのソースとして機能した数学の新しいセクション。

それに注意する必要があります

イディオムを学ぶことは必須です （これが「FPコア」です）。
抽象化の言語メカニズムの学習-再利用に適したイディオムを実装するために実稼働モードで必要です 。
典型的なScala機能ライブラリの研究- できれば、既に作成されデバッグされたイディオムを再利用するための実稼働モードで。
数学の関連セクションを勉強することは、イディオムを理解したり使用したりするために必要ではありません 。

少なくとも、「3つのシフト」を区別できます。カテゴリー、代数、論理（数学のセクションの名前による）

イディオムFP	Scalaギア	Scalaライブラリ	数学のセクション
共変ファンクター、適用ファンクター、モナド、矢印	型クラス、上位のジェネリック	スカラズ、猫	カテゴリー理論
依存ペア、依存関数	パス依存型	形のない	数学的論理
モノイド、グループ、フィールド、リング	型クラス、上位のジェネリック	アルジバード、スパイア	代数

要するに：

上位王のジェネリックは 、再利用可能な抽象化（共変ファンクターなど）を構築するために使用されます。この場合、OOPでは、先祖タイプが通常作成されます。
型クラスは、コードに「抽象化を適用」するために使用されます（ユーザークラスは共変ファンクタに「なります」）。この場合、OOPでは、それらは通常、祖先の抽象化から継承されます。

私たちの例では、より高いking +型クラスのジェネリックを使用しないため、再利用に適合しません（そして、ここでの「古き良きOOPトリック」は特に適していません）。しかし、再利用の準備ができていなくても、この例はイディオムの本質をよく示しています。

カテゴリー理論とHaskellについて

20世紀半ばに、数学の新しい分野が生まれました-カテゴリー理論（数学者自身がしばしば「抽象的なナンセンス」と呼ぶことに注意してください）。カテゴリ理論は、数学の多くの基本領域（集合論、トポロジー、機能分析など）で広く使用されている一般的なアイデア/構造から来ており、現在、すべての数学の基礎/基盤であると主張しています（構築した集合論の群集） 20世紀初頭からの数学）。

しかし、集合論が集合自体（要素、集合の操作、集合のカーディナリティ、構造を持つ集合（順序付き集合、部分順序集合）など）に焦点を合わせている場合、集合のマッピング（集合から集合への関数）は背景にあり、カテゴリー理論では、基礎はカテゴリーですが、簡単に言えば、 category = set + mappingsです。マッピングは関数の同義語です（より正確には、マッピング=引数から値に直接「移動」する手順を指定せずに値のドメインの要素の定義のドメインの要素に対応、マッピング=テーブルで指定された関数、マッピング= fの意味の関数の「外部インターフェイス」 ：A => B 「内部実装」（関数本体）を指定せずに）、ここで、関数自体のような強調は、関数型プログラミングにとって非常に重要であることがわかります。

マッピングに集中すると、豊富な機能的抽象化（ファンクター、モナドなど）が発生し、これらの抽象化は関数型プログラミング言語（Haskellで最も有名な実装）に転送されました。 Scalaの夜明け（2005年から2010年）はHaskellの夜明け（1990年から1995年）に比べて15年間相殺され、多くのことはHaskellからScalaに既製で転送されます。したがって、Scalaプログラマーにとっては、カテゴリー理論自体ではなく、カテゴリー抽象化の主なソースとしてHaskellの実装を扱うことがより重要です。これは、カテゴリー理論=> Haskellの転送中に、多くの重要な詳細が変更、消失、または追加されたという事実によるものです。プログラマーにとって重要ですが、数学者にとっては二次的なものです。

移行の例を次に示します。

共変ファンクターとは

一部の著者は、 Covariant Functorをコンテナーにすることを推奨しています （より正確には、共変Functorはむしろ「コンテナーの半分」です）。この比phorを思い出すことをお勧めしますが、定義ではなく比preciselyとして正確に扱います。

Covariant Functorが「計算コンテキスト」である他の人 。これは生産的なアプローチですが、コンセプトを完全にマスターし、「最大限に活用しよう」とする場合に役立ちます。今のところ無視してください。

さらに他の人は、「より構文的なアプローチ」を提案しています。 Covariant Functorは、特定のメソッドを持つ特定のタイプです。メソッドは特定のルール（2つ）に準拠する必要があります。

「構文アプローチ」を使用し、コンテナ/ストレージのメタファーを使用することをお勧めします。

「構文的アプローチ」の観点から見ると、共変ファンクターは、次のシグネチャを持つメソッド（ mapと呼ぶ）を持つ型パラメーターを持つ任意の型（ Xと呼ぶ）を持つ型です。

trait X[T] { def map(f: T => R): X[R] }

重要：この特性から継承するのではなく、類似のタイプを探します。

「構文的アプローチ」は、多くのカテゴリ構造を一般的なスキームにまとめることができるという点で優れています

 trait X[T] { // covariant functor (functor) def map[R](f: T => R): X[R] // contravariant functor (contravariant) def contramap[R](f: R => T): X[R] // exponential functor (invariant functor) def xmap[R](f: (T => R, R => T)): X[R] // applicative functor def apply[R](f: X[T => R]): X[R] // monad def flatMap[R](f: T => X[R]): X[R] // comonad def coflatMap[R](f: X[T] => R): X[R] }

重要：ここに示されているメソッドは、いくつかの抽象化に必要なもの（共変/反変/指数関数）と、他（適用関数、モナド、コモナ）に必要なメソッドの1つです。

共変ファンクターの例

既にScala（またはJava 8）でプログラミングを開始している人は、すぐに共変ファンクターである多くの「コンテナータイプ」に名前を付けることができます。

オプション

 import java.lang.Integer.toHexString object Demo extends App { val k: Option[Int] = Option(100500) val s: Option[String] = k map toHexString }

または人生に少し近い

 import java.lang.Integer.toHexString object Demo extends App { val k: Option[Int] = Map("A" -> 0, "B" -> 1).get("C") val s: Option[String] = s map toHexString }

お試しください

 import java.lang.Integer.toHexString import scala.util.Try object Demo App { val k: Try[Int] = Try(100500) val s: Try[String] = k map toHexString }

または人生に少し近い

 import java.lang.Integer.toHexString import scala.util.Try object Demo extends App { def f(x: Int, y: Int): Try[Int] = Try(x / y) val s: Try[String] = f(1, 0) map toHexString }

未来

 import java.lang.Integer.toHexString import scala.concurrent.ExecutionContext.Implicits.global import scala.concurrent.Future object Demo extends App { val k: Future[Int] = Future(100500) val s: Future[String] = k map toHexString }

または人生に少し近い

 import java.lang.Integer.toHexString import scala.concurrent.ExecutionContext.Implicits.global import scala.concurrent.Future object Demo extends App { def calc: Int = (0 to 1000000000).sum val k: Future[Int] = Future(calc) val s: Future[String] = k map toHexString }

一覧

 import java.lang.Integer.toHexString object Demo extends App { val k: List[Int] = List(0, 42, 100500) val s: List[String] = k map toHexString }

パーサー

 import java.lang.Integer.toHexString import scala.util.parsing.combinator._ object Demo extends RegexParsers with App { val k: Parser[Int] = """(0|[1-9]\d*)""".r ^^ { _.toInt } val s: Parser[String] = k map toHexString println(parseAll(k, "255")) println(parseAll(s, "255")) } >> [1.4] parsed: 255 >> [1.4] parsed: FF

一般に、例として判断すると、コンテナとしての共変ファンクターの比phorは機能します。本当に

オプション-1つの要素の「コンテナのように」、何かが存在する可能性がある（一部）またはそうでない可能性がある（なし）
試してみてください-ある要素に「コンテナのように」、どこにあるか（成功）またはそうでないかもしれません（失敗、より正確には、要素の代わりに例外があります）。
未来-何かがすでにあるかもしれない、それがうそをついているかもしれない、例外が既にある、または例外がうそをつく、または決してうそをつかない「コンテナのような」要素。
リスト-0〜N個の要素があるコンテナ
パーサーはここではもう少し複雑で、何も「格納」されていません。パーサーは文字列からデータを抽出する方法です。ただし、パーサーはデータソースであり、この点ではコンテナーに似ています。

共変ファンクターは、特定のシグネチャを持つメソッドの存在だけでなく、2つのルールの履行でもあります。ここでの数学者は通常カテゴリー理論を参照し、これらの規則はファンクターがカテゴリー準同型であるという事実の結果であると言います。つまり、構造を保持するカテゴリーへのカテゴリーのマッピングです（そして単一矢印要素はカテゴリー構造の一部です（恒等則規則）および矢印の構成規則（構成法））。

このアプローチは、一般的にプログラミングでは非生産的です。関数型プログラミングでは、機能を維持しながら（通常は最適化の目的で）プログラムを変換するために、これら2つのルールが必要であることを考慮してください。

共変関数：アイデンティティ法

共変の楽しいファンクターの場合、次のルールIdentityLaw.case0（fun）を同一に実行する必要があります-IdentityLaw.case1（fun）と同じです。

 object IdentityLaw { def case0[T](fun: Functor[T]): Functor[T] = identity(fun) def case1[T](fun: Functor[T]): Functor[T] = fun.map(identity) }

ここで、identityはPredef.scalaからの多態的な同一性関数（単位関数）です

 object Predef ... { def identity[A](x: A): A = x ... }

かなり簡単に-fun.map（identity）はファンクター内の何も変更すべきではありません。

これは、バージョンを保存し、各ディスプレイでバージョンを増やすコンテナが、共変ファンクターの上位に対応しないことを意味します

 //  -    class Holder[T](value: T, ver: Int = 0) { def map[R](f: T => R): Holder[R] = new Holder[R](f(value), ver + 1) }

表示操作の回数を「カウント」するため（アイデンティティ関数による表示も）。

しかし、このようなコードはファンクターの最初のルールに対応しています（2番目のルールにも対応しています）。

 //  -   class Holder[T](value: T, ver: Int = 0) { def map[R](f: T => R): Holder[R] = new Holder[R](f(value), ver) }

ここでは、バージョンはデータに単純に添付され、表示時に常に付随します。

共変ファンクター：合成法

共変ファンクター 'fun [T]'および関数 'f：'および 'g'の場合、次のルールCompositionLaw.case0（fun）を同一に実行する必要があります-CompositionLaw.case1（fun）と同じです。

 object Lawompose extends App { def case0[T, R, Q](fun: Functor[T], f: T => R, g: R => Q): Functor[Q] = (fun map f) map g def case1[T, R, Q](fun: Functor[T], f: T => R, g: R => Q): Functor[Q] = fun map (f andThen g) }

つまり、関数「f」で、次に関数「g」で順番に表示される任意のファンクターコンテナーは、関数fとg（f andThen g）の新しい関数構成を作成し、それを1回表示することと同等です。

例を考えてみましょう。コンテナーはしばしばファンクターと見なされるため、ファンクターを再帰的なデータ型（バイナリツリー型コンテナー）にしましょう。

 sealed trait Tree[T] { def map[R](f: T => R): Tree[R] } case class Node[T](value: T, fst: Tree[T], snd: Tree[T]) extends Tree[T] { def map[R](f: T => R) = Node(f(value), fst map f, snd map f) } case class Leaf[T](value: T) extends Tree[T] { def map[R](f: T => R) = Leaf(f(value)) }

ここで、mapメソッド（f：T => R）は、関数 'f'を各リーフまたはノード（リーフ、ノード）のタイプ 'T'の要素に適用し、ノード（ノード）の子孫に再帰的に伝播します。だから私たちは

ツリー構造が保持されます
「木に掛かっている」データの値が変化する

マッピング中にツリーの構造を変更しようとすると、両方の規則に違反します（Identity LawとComposition Lawの両方）。

ファンクタではありません：各ノードの子孫を表示するときにスワップします

 case class Node[T](value: T, fst: Tree[T], snd: Tree[T]) extends Tree[T] { def map[R](f: T => R) = Node(f(value), snd map f, fst map f) }

ファンクタではありません：ディスプレイごとにツリーが成長し、葉が枝に変わります

 case class Leaf[T](value: T) extends Tree[T] { def map[R](f: T => R) = Node(f(value), Leaf(f(value)), Leaf(f(value))) }

このような（誤った）バイナリツリーの実装をファンクターとして見ると、データの表示とともに、ツリーの構造を変更する形でmapの使用回数もカウントしていることがわかります。それで、アイデンティティに反応し、fとgのいくつかの使用法は、fとgの使用法とは異なります。

共変ファンクター：最適化に使用

共変ファンクターの公理の利点を示す例を見てみましょう。

マッピングとして、整数上の線形関数を考えます

 case class LinFun(a: Int, b: Int) { def apply(k: Int): Int = a * k + b def andThen[A](that: LinFun): LinFun = LinFun(this.a * that.a, that.a * this.b + that.b) }

T => Rの形式の最も一般的な関数の代わりに、それらのサブセットを使用します。一般的な形式とは異なり、明示的な形式で線形関数の構成を構築できるため、Int上の線形関数です。

ファンクタとして、単純に整数のリストを連結したタイプの再帰コンテナ（Int）を検討します

 sealed trait IntSeq { def map(f: LinFun): IntSeq } case class Node(value: Int, tail: IntSeq) extends IntSeq { override def map(f: LinFun): IntSeq = Node(f(value), tail.map(f)) } case object Last extends IntSeq { override def map(f: LinFun): IntSeq = Last }

そして今、デモ

 object Demo extends App { val seq = Node(0, Node(1, Node(2, Node(3, Last)))) val f = LinFun(2, 3) // k => 2 * k + 3 val g = LinFun(4, 5) // k => 4 * k + 5 val res0 = (seq map f) map g // slow version val res1 = seq map (f andThen g) // fast version println(res0) println(res1) } >> Node(17,Node(25,Node(33,Node(41,Last)))) >> Node(17,Node(25,Node(33,Node(41,Last))))

私たちはどちらか

リストのすべての要素を2回繰り返します（2回はメモリを通過します）
算術演算を実行するために2回（*および+）

コンポジションfおよびgを構築し、

リストのすべての要素を1回繰り返す
算術演算を1回実行する

反変ファンクターとは

特定のシグネチャ（条件付きでmapと呼ばれる）を持ち、特定のルール（ Identity Law 、 Composition Law ）に従うメソッドを持つすべてのクラスXは共変ファンクターと呼ばれることを思い出させてください

 trait X[T] { def map[R](f: T => R): X[R] }

同様に、特定の署名を持ち、特定の規則（これらはIdentity Law 、 Composition Lawとも呼ばれます）を持つメソッド（条件付きでcontramap ）を持つすべてのクラスXは、反変ファンクターと呼ばれます。

 trait X[T] { def contramap[R](f: R => T): X[R] }

この時点で、当惑したリーダーが停止する場合があります。待ってください。ただし、 Tを含むコンテナがあり、関数f：T => Rを取得する場合、 Rを含むコンテナを取得する方法は明らかです。関数をコンテナに渡し、関数をコンテナ内に浸し、要素を削除せずに関数を適用します。ただし、 Tを含むコンテナを持ち、関数f：R => Tを受け取る方法を「逆順」で適用する方法は完全に理解不能です。

一般的な数学では、すべての関数に逆関数があるわけではなく、逆関数が存在する場合でもそれを見つける一般的な方法はありません。プログラミングでは、建設的に行動する必要があります（存在、一意性などで機能するだけでなく、構成を構築して実行します）-何らかの方法で関数fを構築する必要があります：R => T関数g：T => Rコンテナの内容！

そして、ここで私たちの比phor（共変関手〜コンテナ）が機能しないことがわかります。理由を見てみましょう。

すべてのコンテナには2つの操作が含まれます

put-コンテナにアイテムを入れます
get-コンテナからアイテムを抽出します

ただし、検討されている例（Option、Try、Future、List、Parser）には、ある程度getメソッドがありますが、putメソッドはありません！ Option / Try / Futureでは、要素はコンストラクター（またはコンパニオンオブジェクトのapplyメソッド）または何らかのアクションの結果として取得されます。 Parser [T]-Tの行を「リサイクル」するため、Parserにはまったくアクセスできません。Parser[T]はストレージではなくTのソースです！

そして、ここに隠metaの誤りの秘密があります。

共変ファンクターはコンテナーの半分です。 データの取得を担当する部分。

ダイアグラムに描いてみましょう

      + ------------------------- +
      |  + ------ + T |  R
      |  |  X [T] -----> f：T => R ---->
      |  + ------ + |
      + ------------------------- +

つまり、共変ファンクターの出口では、タイプTのデータ要素は関数f：T => Rを待機し、この構成は、 Rで入力された共変ファンクターです。

この場合、ストレージコンテナーではない理由が明らかになりますが、一般的なIteratorおよびStreamデータソースも共変ファンクターです。
???
???

概略的には、共変ファンクターは次のとおりです。変換fを「ねじ込み」 ます。R=> Tは 「出力」ではなく「入力」です。

      + ------------------------- +
    R |  T + ------ + |
   -----> f：R => T -----> X [T] |  |
      |  + ------ + |
      + ------------------------- +

反変ファンクターの例

Scala標準ライブラリで反変ファンクターの例を検索するには、コンテナーメタファーを忘れて、引数としてデータのみを受け入れ、関数の結果を返さない1つの型パラメーターを持つ型を探す必要があります。

例は、注文と同等です

例：注文

 import scala.math.Ordering._ object Demo extends App { val strX: Ordering[String] = String val f: (Int => String) = _.toString val intX: Ordering[Int] = strX on f }

文字列を相互に比較する方法を持ち、整数を文字列に変換する機能を持つことで、数値を文字列として比較する方法を構築できます。

行に関する簡単なコメント

  val strX: Ordering[String] = String

この場合、java.lang.Stringではなく、scala.math.Ordering.String

 package scala.math trait Ordering[T] extends ... { trait StringOrdering extends Ordering[String] { def compare(x: String, y: String) = x.compareTo(y) } implicit object String extends StringOrdering ... }

onメソッドはcontramapメソッドです

 package scala.math trait Ordering[T] extends ... { def on[R](f: R => T): Ordering[R] = new Ordering[R] { def compare(x: R, y: R) = outer.compare(f(x), f(y)) } ... }

例：同等

 import java.lang.String.CASE_INSENSITIVE_ORDER import scala.math.Equiv import scala.math.Equiv.{fromFunction, fromComparator} object Demo extends App { val strX: Equiv[String] = fromComparator(CASE_INSENSITIVE_ORDER) val f: (Int => String) = _.toString val intX: Equiv[Int] = fromFunction((x, y) => strX.equiv(f(x), f(y))) }

java.lang.String.CASE_INSENSITIVE_ORDERコンパレータメソッドに基づいて、文字列比較メソッド（scala.math.Equizの等価関係）を構築しています。

 package java.lang; public final class String implements ... { public static final Comparator<String> CASE_INSENSITIVE_ORDER = new CaseInsensitiveComparator(); private static class CaseInsensitiveComparator implements Comparator<String>, java.io.Serializable { public int compare(String s1, String s2) {...} ... } ... }

fromComparatorメソッドを使用する

 object Equiv extends ... { def fromComparator[T](cmp: Comparator[T]): Equiv[T] = new Equiv[T] { def equiv(x: T, y: T) = cmp.compare(x, y) == 0 } ... }

コントラマップメソッドの代わりに、fromFunctionメソッドに基づく面倒な構造を使用します

 object Equiv extends ... { def fromFunction[T](cmp: (T, T) => Boolean): Equiv[T] = new Equiv[T] { def equiv(x: T, y: T) = cmp(x, y) } ... }

反変関数：アイデンティティ法

共変ファンクターの場合のように、反変ファンクターは、署名付きのメソッドに加えて、2つのルールに従う必要があります。

最初の規則（同一性法則）には、反変ファンクターの場合、IdentityLaw.case0（fun）は同一でなければならず、IdentityLaw.case1（fun）でなければなりません

 object IdentityLaw { def case0[T](fun: Contravariant[T]): Contravariant[T] = identity(fun) def case1[T](fun: Contravariant[T]): Contravariant[T] = fun.contramap(identity) }

つまり、反変ファンクターと単位関数のマッピングはそれを変更しません。

反変ファンクター：合成法

2番目のルール（構成法）によると、反変ファンクター[T]および関数f：Q => Rおよびg：R => Tの任意のペアの場合、そのペアはIdentityLaw.case1（fun）と同一のIdentityLaw.case0（fun）でなければなりません

 object CompositionLaw { def case0[Q, R, T](fun: Contravariant[T], f: Q => R, g: R => T): Contravariant[Q] = (fun contramap g) contramap f def case1[Q, R, T](fun: Contravariant[T], f: Q => R, g: R => T): Contravariant[Q] = fun contramap (f andThen g) }

つまり、関数のペアによる反変ファンクターの順次マッピングは、関数の構成（反転）によるユニットマッピングと同等です。

次は？

共変および反変ファンクターの概念は、関数型プログラミングにおけるカテゴリ理論からの抽象化の使用に関する真剣な研究の出発点にすぎません（Scalaの用語-CatsライブラリのScalazの使用への移行）。

追加の手順は次のとおりです。

共変および反変のファンクター（BiFunctor、ProFunctor、Exponential（Invariant）Functor）の構成の研究
より特殊な構造（Applicative Functor、Arrow、Monad）の研究。これは、計算、入出力、エラー処理、状態の変化を扱う新しいパラダイムをすでに実際に構成しています。少なくとも、すべてのモナドは共変ファンクターであることを指摘します。

残念ながら、記事のサイズでは、一度にすべてを伝えることはできません。

PSこの記事を最後まで読んだ人のために、 Scala for Java Developersコースを価格の25％で提供しています（リンクをたどるか、 HABR-COVARIANT-FUNCTORクーポンを使用してください ）。割引クーポンの数は限られています！

ScalaのFP：ファンクターとは？

抽象化の言語メカニズムについて

カテゴリー理論とHaskellについて

共変ファンクターとは

共変ファンクターの例

共変関数：アイデンティティ法

共変ファンクター：合成法

共変ファンクター：最適化に使用

反変ファンクターとは

反変ファンクターの例

反変関数：アイデンティティ法

反変ファンクター：合成法

次は？

More articles: