Mengapa tipe rekursif diperlukan sebagai primitif untuk bukti dalam sistem tipe dependen?

10

Saya relatif baru mengetik teori dan pemrograman dependen. Saya telah mempelajari kalkulus konstruksi (CoC) dan sistem tipe murni lainnya. Saya sangat tertarik menggunakannya sebagai representasi perantara untuk sistem kompiler.

Saya mengerti bahwa (co-) tipe rekursif dapat diwakili , secara komputasi , menggunakan sebagai satu-satunya tipe konstruktor. Saya telah membaca, bahwa mereka tidak dapat digunakan untuk membangun bukti dengan induksi (maafkan saya, saya tidak dapat menemukan di mana sekarang!), Misalnya, bahwa saya tidak dapat membuktikan bahwa di CoC biasa (walaupun dapat diketik dengan ).Π01NatΠ(N:).Π(S:NN).Π(Z:N).N

Saya berasumsi inilah sebabnya mereka membangun kalkulus konstruksi induktif (CIC). Apakah ini benar? Tapi kenapa? Saya tidak dapat menemukan bahan yang menjelaskan mengapa bukti tersebut tidak dapat diwakili tanpa menggunakan (co) tipe induktif sebagai primitif. Jika ini tidak benar, lalu mengapa menambahkannya sebagai primitif di CIC?

paulotorrens
sumber

Jawaban:

7

Saya bukan ahli, tetapi saya akan membagikan apa yang saya pahami sejauh ini dengan sebuah contoh.

Mari kita pertimbangkan tipe boolean dalam CoC, menggunakan pengkodean standarnya: Kita mungkin bisa membuktikan Memang, ini dengan cepat mengikuti dari prinsip eliminasi / induksi tergantung kita miliki misalnya dalam CiC

B=Πτ:τττtt=λτ:,x:τ,y:τ. xff=λτ:,x:τ,y:τ. y
Πb:Bb=ttb=ff()
Bind:ΠP:BP(tt)P(ff)Πb:BP(b)

Namun, kita tidak bisa benar-benar berharap (*) bertahan di semua model CoC! Secara intuitif, nilai dalam seharusnya kira-kira merupakan kumpulan fungsi ditetapkan untuk setiap jenis nilai dalam interpretasi dari . Tapi ini tidak memaksa menjadi salah satu di antara nilai . Kita dapat memiliki mis (informal) B{fτ}τττττfτtt,ff

fN(n)(m)=n+m

Untuk memastikan bahwa nilai adalah satu-satunya nilai yang mungkin, kita perlu membatasi diri kita pada model parametrik . Memang (saya pikir) properti dapat dibuktikan dari teorema bebas yang terkait dengan polytype .tt,ff()B

Namun, sejauh yang saya mengerti, CoC tidak mengesampingkan model ad-hoc, di mana parametricity tidak berlaku. Dalam beberapa di antaranya, benar-benar salah. Dengan kesehatan, di hadapan countermodel, kami menyimpulkan bahwa tidak dihuni di CoC. Akibatnya, tidak ada istilah dalam CoC.()()Bind

chi
sumber
Saya tidak yakin saya mengikuti. Misalnya, diberi ekspresi sebagai , ada banyak cara saya bisa membuat konstruktor untuk Nat, tetapi, pada akhirnya, tidakkah semuanya dibangun dari atau ? (λ(Nat:).(...))(Π(N:).Π(S:NN).Π(Z:N).N)SZ
paulotorrens
@ paulotorrens Di dalam logika, ya, saya percaya bahwa ini adalah satu-satunya pilihan. Namun dalam model CoC (model ad-hoc), mungkin ada nilai-nilai dari yang tidak dapat didefinisikan melalui . Pikirkan nilai alami sehingga untuk semua jenis kecuali untuk mana sebaliknya . Nilai berperilaku sebagai "nol" pada sebagian besar tipe, dan sebagai "satu" untuk boolean. Kami tidak dapat menulis dalam CoC untuk menentukan nilai itu , tetapi dalam model ad-hoc nilai itu mungkin tetap ada. NatS,Znn(T)(ST)(ZT)=ZTTT=Bn(B)(S)(Z)=S(Z)nλT:.if T=B then n
chi
@paulotorrens Mungkin Anda bisa memahami masalah ini lebih mudah jika Anda berpikir tentang . Tipe ini hanya dihuni oleh identitas (polimorfik), dan dalam model parametrik itu memang satu-satunya nilai yang mungkin untuk istilah tipe itu. Tetapi, dalam model ad-hoc, kita mungkin mendefinisikan nilai untuk semua jenis tetapi untuk mana . ΠT:TTv(T)(x)=xTT=Nv(N)(x)=x+1
chi