Apa fragmen dari teori tipe dependen Martin-Lof yang dapat diekspresikan menggunakan tipe generik di Jawa?

Saya baru-baru ini datang untuk menyadari bahwa suatu jumlah dari masalah aku punya beberapa tahun yang lalu mencoba untuk menerapkan berbagai teori matematika di Jawa datang ke fakta bahwa sistem mengetik di Jawa tidak cukup kuat untuk model semua Martin-Lof teori jenis tergantung .

Sebelum Java 5 dan generik, satu-satunya jenis teori yang dapat Anda lakukan adalah melalui kelas dan interface, yang memberikan jenis sewenang-wenang dibangun dari jenis tanah int, double, chardan sebagainya menggunakan produk dan fungsi jenis. Anda juga dapat membangun tipe rekursif seperti Lists, meskipun tidak dengan cara yang seragam.

Menggunakan obat generik, Anda dapat melakukan sedikit lebih banyak. Anda sekarang dapat mendefinisikan List<T>sebagai fungsi dan jadi kami mendapatkan jenis pesanan yang lebih tinggi.

$$\DeclareMathOperator{\Type}{Type}\Type\to\Type$$

Ini bukan akhir dari cerita. Menggunakan trik generik, kita dapat memodelkan beberapa jenis produk dependen. Sebagai contoh, kita dapat mendefinisikan tipe formulir menggunakan sintaksis

$$\prod_{T\colon\Type}f(T)$$

public interface f<T extends f<T>>
{
  // We can now refer to T as much as we like
  // inside the class.  T has type f<T>.
}

Sebagai contoh, kita dapat memodelkan struktur dasar yang mendasari monoid (tetapi bukan kondisi asosiatif dan unitality) menggunakan istilah tipe ( yaitu, himpunan dengan elemen unit yang ditunjuk dan operasi biner pada ). Menggunakan Java generics, kita dapat memodelkan tipe ini:

$$\prod_{T\colon\Type}T\times (T\to T\to T)$$ $T$$T$

public interface MonoidElement<T extends MonoidElement<T>>
{
  public T unit();

  public T mul(T op1, T op2);
}

Namun, ketika kami mencoba untuk memodelkan konsep yang lebih rumit, teori tipe itu rusak.

Apakah ada deskripsi sederhana tentang fragmen MLTT yang sesuai dengan tipe yang dapat dibangun di sistem pengetikan Java?

Ada banyak kesalahpahaman di sini. Untuk memulainya, MLTT tidak memiliki subtipe, jadi Java tidak akan menjadi bagian darinya saja. Tidak memerlukan tipe dependen untuk membuat salah satu tipe yang Anda berikan. Sistem tipe dependen tidak perlu memiliki "tipe" tipe (alam semesta) secara umum (MLTT memiliki semesta sekalipun), Anda juga tidak memerlukan tipe dependen untuk mengekspresikan tipe-tipe itu. Dalam sistem seperti kalkulus lambda polimorfik / Sistem F , Anda dapat mengatakan . Java tidak memiliki yang setara dengan Type. Tipe dependen tanpa analog sebagai tipe polimorfik akan menjadi seperti eg atau$\forall T.T\times(T\to T\to T)$$\prod_{n:\mathsf{Nat}}\mathsf{Matrix}(n,n+1)$$\prod_{b:\mathsf{Bool}}\mathsf{if}\ b\ \mathsf{then}\ \mathsf{Nat}\ \mathsf{else}\ \mathsf{Bool}$ .

Lebih masuk akal untuk menganggap Java sebagai fragmen dari System$\text{F}_{<:}$ yang sama sekali bukan sistem tipe dependen. Bahkan kemudian itu adalah fragmen yang agak lemah. Ada varian System F yang disebut System F$\omega$yang mendukung fungsi level tipe penuh, pada dasarnya lambda pada level tipe (jangan dikacaukan dengan tipe-lambdas yang menghubungkan nilai dan level tipe dan Sistem F sudah memiliki). Baik Java maupun Haskell tidak dapat melakukan ini. Satu-satunya tipe level "fungsi" yang dapat dibuat Haskell atau Java (adalah komposisi fungsi yang tidak diinterpretasikan. Tidak ada perilaku komputasi di tingkat tipe. Java lebih lanjut dibatasi karena tidak memiliki (tidak perlu) sistem sejenis karena tidak memiliki jenis yang lebih tinggi. Artinya, Anda tidak dapat memiliki "fungsi" tingkat tipe dengan "tipe" (yaitu tipe) misalnya. Inilah sebabnya mengapa Anda tidak dapat membuat metode yang beroperasi di atas monad arbitrer di Jawa. Kembali ke Sistem F saja, Sistem F memiliki jenis peringkat yang sewenang-wenang.$(\mathsf{Type}\to\mathsf{Type})\to\mathsf{Type}$$\forall$ sedalam yang Anda inginkan - Anda dapat menggunakannya secara bebas. Baik Java maupun Haskell (tanpa ekstensi) mendukung ini. Saya percaya keduanya dapat secara tidak langsung menangkap beberapa jenis peringkat yang lebih tinggi, tetapi tidak satu pun dapat mengekspresikan jenis Haskell yang memerlukan ekstensi dan .$\mathsf{runST}$$\forall a.(\forall s.\mathsf{ST}\ s\ a) \to a$

Jadi Java lebih ekspresif daripada tipe peringkat-1 sebagaimana ditangkap oleh sistem tipe Hindley-Milner tetapi jauh lebih ekspresif daripada Sistem . Itu tidak mendukung segala bentuk pengetikan tergantung. Java Featherweight seperti yang diperkenalkan di Featherweight Java: Kalkulus Inti Minimal untuk Jawa dan GJ oleh Igarashi, Pierce, dan Wadler menyediakan kalkulus yang disederhanakan dan diidealkan, yang secara khusus diarahkan ke Jawa. Hampir pasti ada kertas yang secara langsung membandingkan / mengurangi Featherweight Java ke System . Hasilnya adalah sistem tipe Java bahkan tidak jauh dari kekuatan MLTT. Dalam hal kubus lambda , mengabaikan subtyping, Java akan berada di suatu tempat di antara$\text{F}_{<:}$$\text{F}_{<:}$$\lambda\!\!\to$, kalkulus lambda yang diketik sederhana, dan , System F. MLTT (atau secara khusus Kalkulus Konstruksi) adalah , sudut kebalikan dari . Jadi mendeskripsikan Java dalam hal MLTT pertama-tama harus mengabaikan segala sesuatu yang membuat MLTT berbeda dari Sistem F dan kemudian mengabaikan hampir semua yang membuat Sistem F berbeda dari Sistem F.$\lambda2$$\lambda\text{P}\omega$$\lambda\!\!\to$$\omega$$\omega$