機能パターン: インターフェイスとファンクター

これは、機能パターンというタイトルの一連の記事のパート 3 です。

残りの記事もぜひチェックしてください!

1. モノイド
2. 構成と暗黙性

ジェネリックスとタイプクラス

正しくするには、関数は型チェックを行う必要があり、したがって証明可能です。しかし、さまざまなタイプを処理することを目的とした一般化された関数の場合、これはすぐに問題点として現れます。 double 関数を複数の型にわたって機能させるには、それらを個別に定義する必要があります!

doubleInt :: Int -> Int
doubleChar :: Char -> Char
doubleFloat :: Float -> Float
-- ...

そして、自尊心のあるプログラマーであれば、これにはすでに完全に愕然としていると気づいているはずです。 部分的なアプリケーションを使用してケース処理を構築するためのパターンについて学んだところですが、型シグネチャではそれが許可されておらず、関数には 型チェックを行います。

ありがたいことに、これはほとんどの最新のプログラミング言語にすでに組み込まれている機能です。ジェネリック型を定義することができます。関数シグネチャまたは変数宣言内の一致する位置のみを検証する必要がある

仮説 型。

// c++
template <typename T>
T double(T x) {
    return x*2;
}

// rust
fn double<T>(x: T) -> T {
    return x*2;
}

-- haskell
double :: a -> a
double = (*2)       -- partially applied multiplication

それで問題は解決するはずです!コンパイラにこれらの

ジェネリックが与えられている限り、実行時にどの型を使用する必要があるかを判断できます(実際には、Rustはコンパイル時にこの推論を実行します!)。

ただし、この実装には利点がありますが、上記の Haskell コードでは実際にエラーが発生するため、実際には Haskell コンパイラによって指摘される明らかな欠陥がまだあります。

「*」の使用から生じる「Num a」のインスタンスはありません...

型を定義しましたが、この型が 2 倍になる

容量 を常に持っているとは限りません。確かに、これは数値に対してはすぐに機能しますが、ユーザーが文字列に対して double を呼び出すのを妨げているのは何でしょうか?リスト？これらの型を 2 倍にする事前定義された メソッド がなければ、そもそも引数として許可されるべきではありません。

したがって、

ジェネリックの名前に反して、もう少し具体的でありながらも一般的であるを取得する必要があります。

ここで

typeclasses が登場します。また、命令型の世界では一般に interface としても知られています。繰り返しになりますが、C++ より後に作成された言語を使用している場合は、インターフェイスの実装にアクセスできる必要があります。

インターフェースは、ジェネリックと比較して、その下で

分類できる型の何らかの機能を指​​定します。

これは、以前のコードの修正バージョンです。

double :: (Num a) => a -> a     -- a has to be of typeclass Num
double = (*2)

または Go:

// We first create an interface that is the union of floats and integers.
type Num interface {
    ~int | ~float64
    // ... plus all other num types
}

func double[T Num](a T) T {
    return a * 2
}

簡潔にするために、Haskell は Typescript や Go のインターフェース (純粋な関数規則によってもたらされる制約) などのインターフェースに埋め込まれた状態を実際には処理しないと言います。したがって、インターフェイスの下にある型の必須の

属性 を定義できる場合でも、純粋な インターフェイスでは 関数 または のみを定義する必要があることに注意してください。 >タイプの機能。

このコンテキストでの機能とは、型に 2 倍関数の形で

依存関係 があるかどうかについて話しています。コンパイラーはそれを 2 倍にする方法を教えています?

import Control.Monad (join)

class CanDouble a where
  double :: a -> a

instance CanDouble Int where
  double = (* 2)

instance CanDouble Float where
  double = (* 2)

-- we tell the compiler that doubling a string is concatenating it to itself.
instance CanDouble String where 
  double = join (++)    -- W-combinator, f x = f(x)(x)

そして今、コードの繰り返しに関しては、ほぼ最初の状態に戻っています。面白いと思いませんか?

しかし、実際にこの機能が威力を発揮するのは、実装をきめ細かく制御することです。

戦略 パターンについて聞いたことがあるなら、機能的な意味では、これがまさにその通りです。

quadruple :: (CanDouble a) => a -> a
quadruple = double . double

leftShift :: (CanDouble a) => Int -> a -> a
leftShift n e
  | e <= 0 = n
  | otherwise = leftShift (double n) $ e - 1

これらの関数は型チェックを行うようになりました。これはすべて、CanDouble 型クラスで型を二重化する方法をコンパイラに

教えたためです。

Go でも同様のことを実現できますが、

非プリミティブ 型でのみインターフェイス メソッドを定義できるという大きな注意点があります。つまり、ラッパー構造体をプリミティブ型に定義する必要があります。

type CanDouble interface {
    double() CanDouble
}

type String string
type Number interface {
    ~int | ~float64
    // ... plus all other num types
}

type Num[T Number] struct {
    v T
}

func (s String) double() String {
    return s + s
}

func (n Num[T]) double() Num[T] {
    return Num[T]{n.v * 2}
}

func quadruple(n CanDouble) CanDouble {
    return n.double().double()
}

func leftShift(n CanDouble, e uint) CanDouble {
    for i := uint(0); i < e; i++ {
        n = n.double()
    }

    return n
}

これは正直言ってちょっと残念ですが、インターフェイスを扱うことになるほとんどの時間はカスタム型と構造体を扱うことになるので、心配する必要はありません。

カテゴリー

圏理論は、数学的構造とその関係の一般理論です。

私たちは The Monoid で

圏論 について簡単に取り上げましたが、接近遭遇のみで、そのままにしておきたいと思います。あちこちでこの内容を参照しますが、ご安心ください。以下の内容を理解するのに背景知識は必要ありません。

しかし、私たちが以前に

セットに遭遇したことがあるのは間違いありません。

簡単にまとめると、セットは要素の

コレクションと考えることができます。これらの要素は絶対に 何でも にすることができます。

{ 0, 1, 2, 3, ... }             -- the set of natural numbers
{ a, b, c, ..., z}              -- the set of lowercase letters
{ abs, min, max, ... }          -- the set of `Math` functions in Javascript
{ {0, 1}, {a, b}, {abs, min} }  -- the set of sets containing the first 2 elements of the above sets

Adding on to that, we have these things called morphisms, which we can think of a mapping between elements.

Very big omission here on the definitions of morphisms, in that they are relations between elements, and not strictly functions/mappings,
you can look it up if you are curious.

We can say a function like toUpper() is a morphism between lowercase letters to uppercase letters, just like how we can say double = (*2) is a morphism from numbers to numbers (specifically even numbers).

And if we group these together, the set of elements and their morphisms, we end up with a category.

Again, omission, categories have more constraints such as a Composition partial morphism and identities. But these properties are not that relevant here.

If you have a keen eye for patterns you'd see that there is a parallel to be drawn between categories and our interfaces! The objects (formal name for a category's set of elements) of our category are our instances, and our implementations are our morphisms!

class CanDouble a where
    double :: a -> a

-- `Int` is our set of elements { ... -1, 0, 1, ... }
-- `(* 2)` is a morphism we defined
-- ... (other omissions)
-- ...
-- Therefore, `CanDouble Int` is a Category.
instance CanDouble Int where
    double = (* 2)

Functors

Man, that was a lot to take in. Here's a little bit more extra:

A Functor is a type of a function (also known as a mapping) from category to another category (which can include itself, these are called endofunctors).

What this essentially means, is that it is a transformation on some category that maps every element to a corresponding element, and every morphism to a corresponding morphism. An output category based on the input category.

In Haskell, categories that can be transformed by a functor is described by the following typeclass (which also makes it a category in of itself, that's for you to ponder):

class Functor f where
    fmap :: (a -> b) -> f a -> f b
    -- ...

f here is what we call a type constructor. By itself it isn't a concrete type, until it is accompanied by a concrete type. An example of this would be how an array isn't a type, but an array of Int is. The most common form of a type constructor is as a data type (a struct).

From this definition we can surmise that all we need to give to this function fmap is a function (a -> b) (which is our actual functor, don't think about the naming too much), and this would transform a type f a to type f b, a different type in the same category.

Yes, this means Haskell's Functor typeclass is actually a definition for endofunctors, woops!

If all of that word vomit was scary, a very oversimplified version for the requirement of the Functor typeclass is that you are able to map values to other values in the same category.

Arguably the most common Functor we use are arrays:

instance Functor [] where
--  fmap f [] = []
--  fmap f (a:as) = f a : fmap as

    -- simplified
    fmap :: (a -> b) -> [a] -> [b]
    fmap f arr = map f arr

We are able to map an array of [a] to [b] using our function (or functor) f. The typeconstructor of [] serves as our category, and so our functor is a transformation from one type of an array to another.

So, formally: the map function, though commonly encountered nowadays in other languages and declarative frameworks such as React, is simply the application of an endofunctor on the category of arrays.

Wow. That is certainly a description.

Here are more examples of functors in action:

// Go
type Functor[T any] interface {
    fmap(func(T) T) Functor[T]
}

type Pair[T any] struct {
    a T
    b T
}

type List[T any] struct {
    get []T
}

// Applying a functor to a Pair is applying the function
// to both elements
func (p *Pair[T]) fmap(f func(T) T) Pair[T] {
    return Pair[T]{     // apply f to both a and b
        f(p.a),
        f(p.b),
    }
}

func (a *List[T]) fmap(f func(T) T) List[T] {
    res := make([]T, len(a.get))    // create an array of size len(a.get)

    for i, v := range a.get {
        res[i] = f(v)
    }

    return List[T]{res}
}

-- haskell
data Pair t = P (t, t)

instance Functor Pair where
    fmap f (P (x, y)) = P (f x, f y)

So all that it takes to fall under the Functor (again, endofunctor), interface is to have a definition on how to map the contents of the struct to any other type (including its own).

This is another simplifcation, functors also need to have property of identity and composition.

To put simply, whenever you do a map, you're not only transforming the elements of your array (or struct), you're also transforming the functions you are able to apply on this array (or struct). This is what we mean by mapping both objects and morphisms to different matching objects and morphisms in the same category.

This is important to note as even though we end up in the same category (in this context, we map an array, which results in another array), these might have differing functions or implementations available to them (though most of them will be mapped to their relatively equivalent functions, such as a reverse on an array of Int to reverse on an array of Float).

ここで、単純化しすぎてちょっと混乱してしまいます。定義だけに従えば、sum や concat などの還元関数は、配列のカテゴリからアトムへの関手であると言えますが、これは必ずしもそうではありません。真実。関手ではカテゴリー構造を保存する必要もありますが、カテゴリー理論にあまりにも深く根ざしているため、この記事シリーズでは取り上げません。

---

この記事にアプリケーションよりもずっと多くの数学が含まれていた場合は申し訳ありませんが、これらの定義を理解することは、このシリーズの後半の難しいパターン、つまりアプリカティブと最後にモナドを理解するのに非常に役立ちます。

モナドは、エンドファンクターのカテゴリ内のモノイドです。

もうすぐそこに到着します！ :>

以上が機能パターン: インターフェイスとファンクターの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。