Apa masalah praktis dengan tipe persimpangan dan persatuan?

Saya merancang bahasa pemrograman fungsional sederhana yang diketik secara statis sebagai pengalaman belajar.

Tampaknya sistem tipe yang telah saya implementasikan sejauh ini dapat (dengan sedikit kerja ekstra) menggabungkan tipe persimpangan dan gabungan, misalnya Anda dapat memiliki:

• <Union String Integer>
• <Union Integer Foo>
• Perpotongan kedua tipe di atas akan menjadi dataran Integer
• Persatuan kedua tipe itu akan menjadi <Union String Integer Foo>

Fakta bahwa ini mungkin, tentu saja, tidak perlu berarti itu adalah ide desain yang bagus. Secara khusus, saya agak khawatir tentang kesulitan implementasi menjaga jenis terlepas dan / atau menangani tumpang tindih.

Apa pro / kontra dari menggabungkan fitur-fitur tersebut dalam sistem tipe?

Berikut adalah beberapa hal yang perlu diingat:

• Meskipun kita biasanya berpikir kita tahu apa yang kita maksud dengan persimpangan set-teori dan serikat, sudah ada beberapa yang berbeda mengambil apa sebenarnya persimpangan dan serikat jenis yang . Jadi, ada baiknya menjabarkan ini sebelum Anda memulai implementasi.
• Salah satu elemen yang saya pikir sangat penting untuk memahami persimpangan dan serikat adalah konsep perbaikan tipe , pada dasarnya gagasan bahwa suatu program memiliki "pola dasar" intrinsik tertentu (misalnya, " foo adalah fungsi dari bilangan bulat ke bilangan bulat"), yang dapat kemudian disempurnakan untuk mengekspresikan properti yang lebih tepat (misalnya, " foo mengambil bilangan bulat genap menjadi bilangan bulat genap dan bilangan bulat ganjil ke bilangan bulat ganjil"). Dengan konsep perbaikan di tangan, properti utama yang membedakan persimpangan dan serikat pekerja dari produk dan jumlah adalah bahwa persimpangan / gabungan dari dua jenis hanya dapat dibentuk jika mereka memperbaiki arketipe yang sama. Dengan kata lain, aturan pembentukan tipe untuk persimpangan dan serikat dapat dinyatakan seperti itu (baca "$S \sqsubset A$$S$$A$ $$\frac{S\sqsubset A \quad T \sqsubset A}{S\cap T\sqsubset A}\qquad \frac{S\sqsubset A \quad T \sqsubset A}{S\cup T\sqsubset A}$$ $$\frac{S\sqsubset A \quad T \sqsubset B}{S* T\sqsubset A*B}\qquad \frac{S\sqsubset A \quad T \sqsubset B}{S+T\sqsubset A+B}$$
• Karena persimpangan dan serikat pekerja dapat digunakan untuk membuat pernyataan yang lebih tepat tentang perilaku run-time suatu program, wajar jika mengetik menjadi peka terhadap urutan evaluasi. Sebagai contoh, makalah (2) dan (4) di bawah ini menjelaskan mengapa aturan mengetik dan subtipe "jelas" (dan cukup standar) untuk persimpangan dan serikat pekerja sebenarnya tidak sehat untuk bahasa seperti-ML (karena adanya efek samping dan tidak penghentian). Anda telah diperingatkan!
• Untuk alasan yang sama, inferensi tipe global umumnya menjadi tidak praktis atau tidak dapat ditentukan. Memang, seluruh konsep "tipe utama" bisa dibilang red-herring, karena fungsi dapat memenuhi banyak sifat berbeda yang tidak relevan dengan tujuan penggunaannya (misalnya, " foo mengambil bilangan bulat utama ke bilangan bulat lebih besar dari 7"). Sebaliknya, pendekatan praktis untuk persimpangan dan serikat pekerja (lihat (3) , (4) ) umumnya didasarkan pada kombinasi inferensi dan pengecekan.

Saya kira beberapa poin di atas mungkin terdengar negatif, meskipun saya tidak akan menyebutnya "kontra" tetapi hanya "realitas" dari tipe persimpangan dan persatuan. Di sisi lain, dari perspektif desain bahasa, salah satu alasan untuk membuat upaya mendukung persimpangan dan serikat pekerja (dan untuk memperbaikinya!) Adalah bahwa mereka memungkinkan properti program yang lebih tepat untuk diekspresikan dalam cara yang sedikit tambahan, membutuhkan transformasi jauh lebih drastis daripada, katakanlah, teori tipe dependen.

Daftar bacaan singkat:

1. Desain Bahasa Pemrograman Forsythe oleh John C. Reynolds
2. Jenis Persimpangan dan Efek Komputasi oleh Rowan Davies dan Frank Pfenning
3. Pemeriksaan Praktis-Perbaikan Tipe oleh Rowan Davies (disertasi)
4. Pengecekan Tiga Arah oleh Joshua Dunfield dan Frank Pfenning