なぜより高い種類が必要なのですか？

いくつかの言語は、（例えば、型パラメータを持つクラスおよび機能を可能にするList<T>場合T、任意のタイプであってもよいです）。たとえば、次のような関数を使用できます。

List<S> Function<S, T>(List<T> list)

ただし、一部の言語では、この概念を1レベル上に拡張して、署名付きの機能を使用できます。

K<S> Function<K<_>, S, T>(K<T> arg)

K<_>それ自体がそのような型である場合List<_>、型パラメーターがあります。この「部分型」は、型コンストラクターとして知られています。

私の質問は、なぜこの能力が必要なのですか？List<T>すべてList<T>がほぼ同じであるが、すべてK<_>が完全に異なる可能性があるため、次のような型を持つことは理にかなっています。共通の機能をまったく持たないOption<_>とを持つことができますList<_>。

他の誰も質問に答えていないので、私は自分でやってみようと思います。私は少し哲学を取得する必要があります。

ジェネリックプログラミングは、型情報を失うことなく、同様の型を抽象化することです（これはオブジェクト指向の値多態性で起こります）。これを行うには、使用できるインターフェイス（OOの用語ではなく、一連の操作）を必ず共有する必要があります。

オブジェクト指向言語では、型はクラスのおかげでインターフェースを満たします。各クラスには、その型の一部として定義された独自のインターフェイスがあります。すべてのクラスList<T>が同じインターフェースを共有しているため、T選択に関係なく機能するコードを作成できます。インターフェイスを課すもう1つの方法は、継承の制約です。この2つは異なっているように見えますが、考えてみると似ています。

ほとんどのオブジェクト指向言語でList<>は、それ自体は適切な型ではありません。メソッドがないため、インターフェイスがありません。List<T>これらのものがあるのはそれだけです。基本的に、より技術的な用語では、意味のある抽象化できる型はkindを持つ型のみです*。オブジェクト指向の世界でより種類の高い型を使用するには、この制限と一致する方法で型制約を表現する必要があります。

例えば、コメントで述べたように、我々は見ることができますOption<>し、List<>あなたが機能を持っている場合、あなたは変換することができることを意味において、「マッピング可能」とOption<T>にOption<S>、またはList<T>にList<S>。クラスを使用して上位の型を直接抽象化することはできないことを思い出して、代わりにインターフェイスを作成します。

IMappable<K<_>, T> where K<T> : IMappable<K<_>, T>

そして、インターフェイスを両方List<T>とOption<T>as IMappable<List<_>, T>でIMappable<Option<_>, T>それぞれ実装します。私たちがやったことは、より高い種類の型を使用して、実際の（より高い種類Option<T>でない）型とに制約を設定することですList<T>。これがScalaで行われている方法ですが、もちろんScalaには特徴、型変数、暗黙的なパラメーターなどの機能があり、表現力を高めています。

他の言語では、より高い種類の型を直接抽象化できます。型システムの最高権威の1つであるHaskellでは、より高い種類の型クラスであっても、任意の型の型クラスを表現できます。例えば、

class Mappable mp where
    map :: mp a -> mp b

これは、mp1つの型パラメーターを受け取る（指定されていない）型に直接配置される制約でありmap、をにmp<a>変換する関数に関連付ける必要がありますmp<b>。その後Mappable、オブジェクト指向言語で継承制約を設定できるように、より種類の高い型を制約する関数を作成できます。まあ、ちょっと。

まとめると、より高い種類の型を使用する能力は、それらを制約する能力、または型制約の一部として使用する能力に依存します。