存在タイプとは何ですか？

Wikipediaの記事「存在タイプ」を読みました。実在演算子（∃）があるため、実在型と呼ばれていることを知りました。でも、その意味がよくわかりません。違いは何ですか

T = ∃X { X a; int f(X); }

そして

T = ∀x { X a; int f(X); }

？

誰か∀Xが言っているユニバーサルタイプを定義すると、次のようになります：好きなタイプをプラグインできXます。私の仕事をするためにタイプについて何も知る必要はありません。それを不透明に参照するだけです。

誰かが存在タイプ∃Xを定義するとき、彼らは言っています：私はここで私が欲しいどんなタイプでも使います; あなたはタイプについて何も知らないので、あなたはそれを不透明に参照することができるだけですX。

ユニバーサルタイプを使用すると、次のように記述できます。

void copy<T>(List<T> source, List<T> dest) {
   ...
}

copy機能はないアイデアを持っていないものをT、実際になりますが、それはする必要はありません。

存在するタイプは、次のようなものを書くことができます：

interface VirtualMachine<B> {
   B compile(String source);
   void run(B bytecode);
}

// Now, if you had a list of VMs you wanted to run on the same input:
void runAllCompilers(List<∃B:VirtualMachine<B>> vms, String source) {
   for (∃B:VirtualMachine<B> vm : vms) {
      B bytecode = vm.compile(source);
      vm.run(bytecode);
   }
}

リスト内の各仮想マシン実装は、異なるバイトコードタイプを持つことができます。runAllCompilersこの関数は、バイトコードの種類が何であるかわかりませんが、それはする必要はありません。それがするすべてはからVirtualMachine.compileにバイトコードをリレーすることですVirtualMachine.runです。

Javaタイプのワイルドカード（例： List<?>は、存在タイプの非常に限定された形式です。

更新：ユニバーサルタイプを使用して存在タイプをシミュレートできることを忘れてしまいました。まず、ユニバーサル型をラップして、型パラメーターを非表示にします。次に、制御を反転します（これにより、上記の定義の「あなた」と「I」の部分が効果的に入れ替わります。これは、存在と普遍の主な違いです。）

// A wrapper that hides the type parameter 'B'
interface VMWrapper {
   void unwrap(VMHandler handler);
}

// A callback (control inversion)
interface VMHandler {
   <B> void handle(VirtualMachine<B> vm);
}

これで、普遍的に型付けされた関数を持つVMWrapper独自の呼び出しを作成できます。正味の効果は同じで、コードは不透明として処理する必要があります。VMHandlerhandleB

void runWithAll(List<VMWrapper> vms, final String input)
{
   for (VMWrapper vm : vms) {
      vm.unwrap(new VMHandler() {
         public <B> void handle(VirtualMachine<B> vm) {
            B bytecode = vm.compile(input);
            vm.run(bytecode);
         }
      });
   }
}

VMの実装例：

class MyVM implements VirtualMachine<byte[]>, VMWrapper {
   public byte[] compile(String input) {
      return null; // TODO: somehow compile the input
   }
   public void run(byte[] bytecode) {
      // TODO: Somehow evaluate 'bytecode'
   }
   public void unwrap(VMHandler handler) {
      handler.handle(this);
   }
}

値実存型などが∃x. F(x) ペアであるいくつかの含有タイプ x及び値タイプのをF(x)。以下のような多相型の値に対し、∀x. F(x)ある機能ある種かかりx且つ生産タイプの値F(x)。どちらの場合も、型はいくつかの型コンストラクターで閉じますF。

このビューではタイプと値が混在していることに注意してください。存在証明は、1つのタイプと1つの値です。普遍的な証明は、タイプ（またはタイプから値へのマッピング）でインデックス付けされた値のファミリー全体です。

したがって、指定した2つのタイプの違いは次のとおりです。

T = ∃X { X a; int f(X); }

つまり、typeの値にTは、という型X、value a:X、およびfunction が含まれますf:X->int。タイプの値のプロデューサは、任意のタイプTを選択できX、コンシューマはについて何も知ることができませんX。その一つの例があると呼ばれることを除いてa、この値をに変えることができることをintにそれを与えることによってf。つまり、typeの値はT、intどういうわけか生成する方法を知っています。さて、私たちは中間型Xを排除し、ただ次のように言うことができます：

T = int

普遍的に定量化されたものは少し異なります。

T = ∀X { X a; int f(X); }

つまり、typeの値にはT任意のtypeを指定できX、値が何であっても、値a:Xと関数を生成します。つまり、タイプの値のコンシューマは、の任意のタイプを選択できます。また、タイプの値のプロデューサは、について何も知ることができませんが、の任意の選択に対して値を生成でき、そのような値をに変換できる必要がありますf:X->int XTXTXaXint。

考えられるすべての型の値を生成できるプログラムがないため、この型の実装は明らかに不可能です。あなたが不条理を許可しない限りnullまたは底の。

実存論はペアであるため、カリー化によって実存論の引数を普遍的なものに変換できます。

(∃b. F(b)) -> Int

と同じです：

∀b. (F(b) -> Int)

前者は、ランク2の存在です。これにより、次の便利なプロパティが得られます。

すべての実存的に定量化されたタイプのランクn+1は、普遍的に定量化されたタイプのランクnです。

Skolemizationと呼ばれる、存在をユニバーサルに変換するための標準アルゴリズムがあります。

2つの概念は相補的であるため、つまり、一方が他方の「反対」であるため、存在型をユニバーサル型と一緒に説明することには意味があると思います。

実存型についてのすべての詳細（正確な定義を与える、考えられるすべての使用法、抽象データ型との関係などをリストするなど）に答えることはできません。このHaskellWiki記事が実存型の主な効果であると述べていることだけを（Javaを使用して）示します。

存在タイプは、いくつかの異なる目的に使用できます。しかし、彼らがしていることは、右側の型変数を「隠す」ことです。通常、右側に表示される型変数は左側にも表示される必要があります[…]

設定例：

次の疑似コードは、それを修正するのは簡単ですが、Javaとしては有効ではありません。実際、それがまさに私がこの答えでやろうとしていることです！

class Tree<α>
{
    α       value;
    Tree<α> left;
    Tree<α> right;
}

int height(Tree<α> t)
{
    return (t != null)  ?  1 + max( height(t.left), height(t.right) )
                        :  0;
}

これについて簡単に説明します。定義しています…

• Tree<α>二分木のノードを表す再帰型。各ノードvalueはあるタイプの αを、同じタイプのオプションleftおよびrightサブツリーへの参照を持っています。

• height葉ノードからルートノードまでの最遠距離を返す関数t。

さて、上の疑似コードを height適切なJava構文に！（簡潔にするために、オブジェクト指向やアクセシビリティ修飾子などのボイラープレートは省略し続けます。）2つの可能な解決策を示します。

1.ユニバーサルタイプソリューション：

最も明白な修正はheight、型パラメーターαをシグニチャーに導入することにより、単純にジェネリックにすることです。

<α> int height(Tree<α> t)
{
    return (t != null)  ?  1 + max( height(t.left), height(t.right) )
                        :  0;
}

これにより、変数を宣言し、タイプαの式を作成できます。応じて、、その関数内。だが...

2.実存型ソリューション：

メソッドの本体を見ると、タイプαの何かに実際にアクセスしたり、操作したりしていないことがわかります。その型を持つ式も、その型で宣言された変数もないので、なぜheight総称にする必要があるのでしょうか。なぜαを単純に忘れられないのですか？結局のところ、次のことが可能です。

int height(Tree<?> t)
{
    return (t != null)  ?  1 + max( height(t.left), height(t.right) )
                        :  0;
}

この回答の冒頭で書いたように、実存型と普遍型は本質的に相補的/二重です。したがって、普遍的な型の解決策がheight よりジェネリックにすることである場合、存在型は逆の効果があることを期待する必要があります：ジェネリックを少なくする、つまり型パラメーターαを非表示 /削除する。

その結果、t.value識別子がバインドされていないため、このメソッドでの型を参照したり、その型の式を操作したりすることができなくなります。（?ワイルドカードは特殊なトークンであり、タイプを「キャプチャーする」識別子ではありません。）t.value事実上不透明になりました。おそらくそれを使ってできる唯一のことは、それを型キャストすることですObjectです。

概要：

===========================================================
                     |    universally       existentially
                     |  quantified type    quantified type
---------------------+-------------------------------------
 calling method      |                  
 needs to know       |        yes                no
 the type argument   |                 
---------------------+-------------------------------------
 called method       |                  
 can use / refer to  |        yes                no  
 the type argument   |                  
=====================+=====================================

これらはすべて良い例ですが、少し違った方法で答えることにしました。数学から思い出してください。P（x）は、「すべてのxについて、P（x）であることを証明できる」という意味です。言い換えれば、それは一種の関数であり、あなたは私にxを与え、私はあなたのためにそれを証明する方法を持っています。

型理論では、証明についてではなく、型について話します。したがって、このスペースでは、「あなたが私に与えるどんなタイプXについても、私はあなたに特定のタイプPを与える」という意味です。さて、PはXについて、それが型であるという事実を除いて、あまり情報を提供しないので、PはXについてはあまり実行できませんが、いくつかの例があります。Pは、「同じタイプのすべてのペア」のタイプを作成できますP<X> = Pair<X, X> = (X, X)。または、オプションtype：を作成することもできますP<X> = Option<X> = X | Nil。ここで、Nilはnullポインターのタイプです。それからリストを作ることができます：List<X> = (X, List<X>) | Nil。最後のList<X>要素は再帰的であり、の値は、最初の要素がXで2番目の要素がaであるペア、List<X>またはnullポインタであることに注意してください。

今、数学∃xで。P（x）は、「P（x）が真になるような特定のxがあることを証明できる」ことを意味します。そのようなxはたくさんあるかもしれませんが、それを証明するには1つで十分です。それを考える別の方法は、空ではない証拠と証明のペアのセット{（x、P（x））}が存在しなければならないということです。

型理論に変換：ファミリー∃X.P<X>の型は、型Xと対応する型P<X>です。XをPに与える前に（Xについてはすべて知っているが、Pはほとんど知らないように）、反対が今は真であることに注意してください。P<X>Xに関する情報を提供することを約束するものではありません。Xが存在し、それが実際に型であるということだけです。

これはどのように役立ちますか？ええと、Pはその内部型Xを公開する方法を持つ型である可能性があります。例として、その状態Xの内部表現を非表示にするオブジェクトがあります。直接操作する方法はありませんが、その効果を観察することができます。 Pを突っ込んでください。このタイプの実装は多数ある可能性がありますが、どのタイプを選択しても、これらすべてのタイプを使用できます。

質問に直接回答するには：

ユニバーサルタイプでは、の使用にTタイプパラメータを含める必要がありますX。たとえばT<String>またはT<Integer>。存在する型のT場合、その型パラメーターは不明または無関係であるため、使用しないでください。使用するのはT（またはJavaでT<?>）だけです。

さらに詳しい情報：

ユニバーサル/抽象型と実存型は、オブジェクト/関数のコンシューマー/クライアントとそのプロデューサー/実装の間の二重の視点です。一方が普遍的なタイプを見るとき、もう一方は存在タイプを見る。

Javaでは、ジェネリッククラスを定義できます。

public class MyClass<T> {
   // T is existential in here
   T whatever; 
   public MyClass(T w) { this.whatever = w; }

   public static MyClass<?> secretMessage() { return new MyClass("bazzlebleeb"); }
}

// T is universal from out here
MyClass<String> mc1 = new MyClass("foo");
MyClass<Integer> mc2 = new MyClass(123);
MyClass<?> mc3 = MyClass.secretMessage();

• 観点からクライアントのMyClass、Tあなたがのために任意の型に置き換えることができますので、普遍的ですTあなたは、そのクラスを使用するときに、あなたがのインスタンスを使用するたびに、Tの実際の型を知っている必要がありますMyClass
• インスタンスメソッドMyClass自体の観点から、T、実際のタイプがわからないため存在T
• Javaでは?、存在型を表します-したがって、クラスの内部にいるときTは基本的に?です。のインスタンスMyClassをTexistentialで処理する場合は、上記MyClass<?>のsecretMessage()例のように宣言できます。

他の場所で説明されているように、存在するタイプは、何かの実装の詳細を隠すために使用されることがあります。このJavaバージョンは次のようになります。

public class ToDraw<T> {
    T obj;
    Function<Pair<T,Graphics>, Void> draw;
    ToDraw(T obj, Function<Pair<T,Graphics>, Void>
    static void draw(ToDraw<?> d, Graphics g) { d.draw.apply(new Pair(d.obj, g)); }
}

// Now you can put these in a list and draw them like so:
List<ToDraw<?>> drawList = ... ;
for(td in drawList) ToDraw.draw(td);

これを適切にキャプチャするのは少し難しいです。Javaがそうではない、ある種の関数型プログラミング言語にいるふりをしているからです。しかし、ここでのポイントは、ある種の状態とその状態を操作する関数のリストをキャプチャしていて、状態部分の実際のタイプがわからないということですが、関数はすでにそのタイプと一致しているため、 。

現在、Javaでは、すべての非最終的な非プリミティブ型が部分的に存在しています。これは奇妙に聞こえるかもしれませObjectんが、として宣言された変数が潜在的にObject代わりにのため、特定の型を宣言することはできず、「この型またはサブクラス」のみを宣言できます。したがって、オブジェクトは状態のビットとその状態で動作する関数のリストとして表されます-呼び出す関数は実行時にルックアップによって決定されます。これは、存在状態の部分とその状態を操作する関数がある場合の上記の存在型の使用によく似ています。

サブタイプやキャストのない静的に型付けされたプログラミング言語では、存在型を使用すると、型の異なるオブジェクトのリストを管理できます。のリストにT<Int>を含めることはできませんT<Long>。ただし、のリストにT<?>はのバリエーションを含めることができ、Tさまざまな種類のデータをリストに入れて、それらをすべてintに変換する（またはデータ構造内で提供される操作を実行する）ことができます。

ほとんどの場合、存在型のレコードをクロージャーを使用せずにレコードに変換できます。クロージャも実在的に型付けされており、閉じられた自由変数は呼び出し元から隠されています。したがって、クロージャをサポートするが存在型をサポートしない言語を使用すると、オブジェクトの存在部分に入れたのと同じ隠された状態を共有するクロージャを作成できます。

存在型は不透明な型です。

Unixのファイルハンドルについて考えてみます。あなたはその型がintであることを知っているので、簡単に偽造することができます。たとえば、ハンドル43から読み取ろうとすることができます。プログラムがこの特定のハンドルでファイルを開いている場合は、そこから読み取ります。あなたのコードは悪質である必要はありません、ずさんなだけです（例えば、ハンドルは初期化されていない変数であるかもしれません）。

存在タイプはプログラムから隠されています。fopen存在タイプが返された場合、それを使用してできることは、この存在タイプを受け入れるいくつかのライブラリ関数で使用することだけです。たとえば、次の疑似コードはコンパイルされます。

let exfile = fopen("foo.txt"); // No type for exfile!
read(exfile, buf, size);

インターフェース「read」は次のように宣言されています。

次のようなタイプTが存在します。

size_t read(T exfile, char* buf, size_t size);

変数exfileは、int、a char*、struct Fileではなく、型システムで表現できるものではありません。型が不明な変数を宣言することはできず、ポインタをその不明な型にキャストすることもできません。言語はあなたをさせません。

私は少し遅れているようですが、とにかく、このドキュメントは存在タイプが何であるかについての別の見方を追加します、特に言語に依存しませんが、存在タイプを理解することはかなり簡単になるはずです： .nl / groups / ST / Projects / ehc / ehc-book.pdf（第8章）

普遍的と実存的に定量化されたタイプの違いは、次の観察によって特徴付けることができます。

• ∀数量化タイプの値を使用すると、数量化タイプ変数のインスタンス化に選択するタイプが決まります。たとえば、識別関数「id ::∀aa→a」の呼び出し元は、この特定のidアプリケーションのタイプ変数aに選択するタイプを決定します。関数アプリケーション「id 3」の場合、このタイプはIntと同じです。

• ∃数量化タイプの値を作成すると、数量化タイプ変数のタイプが決定され、非表示になります。たとえば、「∃a。（a、a→Int）」の作成者は、「（3、λx→x）」からその型の値を作成した可能性があります。別の作成者が「（ 'x'、λx→ord x）」から同じ型の値を作成しました。ユーザーの観点から見ると、両方の値は同じタイプであり、したがって交換可能です。値には、型変数aに対して選択された特定の型がありますが、どの型かわからないため、この情報を利用することはできません。この値固有のタイプ情報は「忘れられました」。私たちはそれが存在することを知っているだけです。

タイプパラメータのすべての値にユニバーサルタイプが存在します。存在タイプは、存在タイプの制約を満たすタイプパラメータの値に対してのみ存在します。

たとえば、Scalaで存在型を表現する1つの方法は、いくつかの上限または下限に制約されている抽象型です。

trait Existential {
  type Parameter <: Interface
}

同様に、制約付きユニバーサルタイプは、次の例のように存在タイプです。

trait Existential[Parameter <: Interface]

のInterfaceインスタンス化可能なサブタイプはExistential、type Parameterを実装する必要があるを定義する必要があるため、どの使用サイトでもを使用できますInterface。

縮重場合 Scalaで実存タイプのが参照されることはないので、任意のサブタイプによって定義される必要はない抽象型です。これは事実上List[_] 、ScalaとList<?>Javaの略記です。

私の答えは、抽象型と実存型を統合するというマーティンオデルスキーの提案に触発されました。付属のスライドは、理解の助けとなります。

抽象データ型と情報隠蔽の研究により、実存型がプログラミング言語に取り入れられました。データ型を抽象化すると、その型に関する情報が非表示になるため、その型のクライアントはそれを悪用することはできません。オブジェクトへの参照を持っているとしましょう...一部の言語では、その参照をバイトへの参照にキャストして、そのメモリの一部に対して必要なことを何でも実行できます。プログラムの動作を保証するために、オブジェクトの設計者が提供するメソッドを介して、オブジェクトへの参照のみを操作することを言語が強制すると便利です。タイプが存在することはわかっていますが、それ以上はありません。

見る：

抽象型には存在型、MITCHEL＆PLOTKINがあります

http://theory.stanford.edu/~jcm/papers/mitch-plotkin-88.pdf

この図を作成しました。厳密かどうかわかりません。しかし、それが役に立てば、私は嬉しいです。

私が理解しているように、それはインターフェース/抽象クラスを記述する数学的な方法です。

T =∃X{X a; int f（X）; }

C＃の場合、汎用の抽象型に変換されます。

abstract class MyType<T>{
    private T a;

    public abstract int f(T x);
}

「存在する」とは、ここで定義された規則に従うタイプがあることを意味します。