Jika sesuatu itu sederhana, maka itu harus sepenuhnya dijelaskan dengan beberapa kata. Ini dapat dilakukan untuk kalkulus λ:

Kalkulus λ adalah tata bahasa sintaksis (pada dasarnya, struktur) dengan aturan reduksi (yang berarti prosedur pencarian / penggantian berulang kali diterapkan pada setiap kemunculan pola tertentu hingga tidak ada pola seperti itu).

Tatabahasa:

Term = (Term Term) | (λ Var . Term) | Var

Aturan pengurangan:

((λ var body) term) -> SUBS(body,var,term)
    where `SUBS` replaces all occurrences of `var`
    by `term` in `body`, avoiding name capture.

Contoh:

(λ a . a)                             -> (λ a a)
((λ a . (λ b . (b a))) (λ x . x))     -> (λ b . (b (λ x x)))
((λ a . (a a)) (λ x . x))             -> (λ x . x)
((λ a . (λ b . ((b a) a))) (λ x . x)) -> (λ b . ((b (λ x . x)) (λ x . x)))
((λ x . (x x)) (λ x . (x x)))         -> never halts

Meskipun agak informal, orang bisa berpendapat ini cukup informatif bagi manusia normal untuk memahami kalkulus λ secara keseluruhan - dan dibutuhkan 22 garis penurunan harga. Saya mencoba memahami sistem tipe murni / dependen seperti yang digunakan oleh Idris / Agda dan proyek-proyek serupa, tetapi penjelasan singkat yang bisa saya temukan adalah Simply Easy - sebuah makalah yang hebat, tetapi itu sepertinya mengasumsikan banyak pengetahuan sebelumnya (Haskell, inductive definisi) yang tidak saya miliki. Saya pikir sesuatu yang lebih singkat, kurang kaya bisa menghilangkan beberapa hambatan itu. Demikian,

Apakah mungkin untuk memberikan penjelasan singkat dan lengkap tentang sistem tipe murni / dependen, dalam format yang sama dengan yang saya sajikan pada kalkulus λ di atas?

Penolakan

Ini sangat informal, seperti yang Anda minta.

Tata bahasa

Dalam bahasa yang diketik secara dependen, kami memiliki pengikat di tingkat tipe serta di tingkat nilai:

Term = * | (∀ (Var : Term). Term) | (Term Term) | (λ Var. Term) | Var

Istilah yang diketik dengan baik adalah istilah dengan tipe terlampir, kami akan menulis t ∈ σatau

σ
t

untuk menunjukkan bahwa istilah tersebut tmemiliki tipe σ.

Aturan mengetik

Demi kesederhanaan, kami mengharuskan λ v. t ∈ ∀ (v : σ). τkeduanya λdan ∀mengikat variabel yang sama ( vdalam hal ini).

Aturan:

t ∈ σ is well-formed if σ ∈ * and t is in normal form (0)

*            ∈ *                                                 (1)
∀ (v : σ). τ ∈ *             -: σ ∈ *, τ ∈ *                     (2)
λ v. t       ∈ ∀ (v : σ). τ  -: t ∈ τ                            (3)
f x          ∈ SUBS(τ, v, x) -: f ∈ ∀ (v : σ). τ, x ∈ σ          (4)
v            ∈ σ             -: v was introduced by ∀ (v : σ). τ (5)

Jadi, *adalah "tipe semua tipe" (1), ∀bentuk tipe dari tipe (2), abstraksi lambda memiliki tipe pi (3) dan jika vdiperkenalkan oleh ∀ (v : σ). τ, maka vmemiliki tipe σ(5).

"dalam bentuk normal" berarti kami melakukan pengurangan sebanyak mungkin menggunakan aturan pengurangan:

Aturan pengurangan "The"

(λ v. b ∈ ∀ (v : σ). τ) (t ∈ σ) ~> SUBS(b, v, t) ∈ SUBS(τ, v, t)
    where `SUBS` replaces all occurrences of `v`
    by `t` in `τ` and `b`, avoiding name capture.

Atau dalam sintaks dua dimensi di mana

σ
t

berarti t ∈ σ:

(∀ (v : σ). τ) σ    SUBS(τ, v, t)
                 ~>
(λ  v     . b) t    SUBS(b, v, t)

Ini hanya mungkin untuk menerapkan abstraksi lambda ke suatu istilah ketika istilah tersebut memiliki tipe yang sama dengan variabel dalam semua kuantifier terkait. Kemudian kita mengurangi abstraksi lambda dan kuantifikasi forall dengan cara yang sama seperti pada kalkulus lambda murni sebelumnya. Setelah mengurangi bagian level nilai, kami mendapatkan (4) aturan mengetik.

Sebuah contoh

Inilah operator aplikasi fungsi:

∀ (A : *) (B : A -> *) (f : ∀ (y : A). B y) (x : A). B x
λ  A       B            f                    x     . f x

(kita menyingkat ∀ (x : σ). τke σ -> τjika τtidak menyebutkan x)

fpengembalian B yuntuk semua yjenis yang disediakan A. Kami menerapkan funtuk x, yang merupakan dari jenis yang tepat A, dan pengganti yuntuk xdi ∀setelah ., sehingga f x ∈ SUBS(B y, y, x)~> f x ∈ B x.

Sekarang mari kita menyingkat operator aplikasi fungsi appdan menerapkannya sendiri:

∀ (A : *) (B : A -> *). ?
λ  A       B          . app ? ? (app A B)

Saya menempatkan ?persyaratan yang harus kami sediakan. Pertama-tama kami secara eksplisit memperkenalkan dan membuat instantiate Adan B:

∀ (f : ∀ (y : A). B y) (x : A). B x
app A B

Sekarang kita perlu menyatukan apa yang kita miliki

∀ (f : ∀ (y : A). B y) (x : A). B x

yang sama dengan

(∀ (y : A). B y) -> ∀ (x : A). B x

dan apa yang app ? ?diterima

∀ (x : A'). B' x

Ini menghasilkan

A' ~ ∀ (y : A). B y
B' ~ λ _. ∀ (x : A). B x -- B' ignores its argument

(lihat juga Apa itu predicativity? )

Ekspresi kami (setelah diganti nama) menjadi

∀ (A : *) (B : A -> *). ?
λ  A       B          . app (∀ (x : A). B x) (λ _. ∀ (x : A). B x) (app A B)

Karena untuk apa pun A, Bdan f(di mana f ∈ ∀ (y : A). B y)

∀ (y : A). B y
app A B f

kita bisa instantiate Adan Bmendapatkan (untuk apa pun fdengan tipe yang sesuai)

∀ (y : ∀ (x : A). B x). ∀ (x : A). B x
app (∀ (x : A). B x) (λ _. ∀ (x : A). B x) f

dan tipe tanda tangan setara dengan (∀ (x : A). B x) -> ∀ (x : A). B x.

Seluruh ekspresi itu

∀ (A : *) (B : A -> *). (∀ (x : A). B x) -> ∀ (x : A). B x
λ  A       B          . app (∀ (x : A). B x) (λ _. ∀ (x : A). B x) (app A B)

Yaitu

∀ (A : *) (B : A -> *) (f : ∀ (x : A). B x) (x : A). B x
λ  A       B            f                    x     .
    app (∀ (x : A). B x) (λ _. ∀ (x : A). B x) (app A B) f x

yang setelah semua pengurangan pada level nilai memberikan appkembali yang sama .

Jadi sementara ini hanya memerlukan beberapa langkah dalam kalkulus lambda murni untuk mendapatkan appdari app app, dalam pengaturan diketik (dan terutama ketergantungan diketik) kami juga perlu peduli tentang unifikasi dan hal-hal menjadi lebih kompleks bahkan dengan beberapa kenyamanan yang tidak konsisten ( * ∈ *).

Ketik memeriksa

• Jika tini *kemudian t ∈ *oleh (1)
• Jika tadalah ∀ (x : σ) τ, σ ∈? *, τ ∈? *(lihat catatan tentang ∈?bawah) kemudian t ∈ *oleh (2)
• Jika tadalah f x, f ∈ ∀ (v : σ) τuntuk beberapa σdan τ, x ∈? σkemudian t ∈ SUBS(τ, v, x)oleh (4)
• Jika tvariabel v, vdiperkenalkan ∀ (v : σ). τsaat itu t ∈ σoleh (5)

Ini semua adalah aturan inferensi, tetapi kami tidak dapat melakukan hal yang sama untuk lambdas (inferensi tipe tidak dapat ditentukan untuk tipe dependen). Jadi untuk lambda kita periksa ( t ∈? σ) daripada menyimpulkan:

• Jika tini λ v. bdan diperiksa terhadap ∀ (v : σ) τ, b ∈? τmakat ∈ ∀ (v : σ) τ
• Jika tada sesuatu yang lain dan diperiksa, σmaka simpulkan jenis tpenggunaan fungsi di atas dan periksa apakah ituσ

Pemeriksaan kesetaraan untuk tipe mengharuskan mereka dalam bentuk normal, jadi untuk memutuskan apakah tmemiliki tipe, σpertama kita periksa yang σmemiliki tipe *. Jika demikian, maka σdapat dinormalisasi (modulo Girard's paradox) dan menjadi dinormalisasi (maka σmenjadi terbentuk dengan baik oleh (0)). SUBSjuga menormalkan ekspresi untuk dipertahankan (0).

Ini disebut pengecekan jenis dua arah. Dengan itu kita tidak perlu membubuhi keterangan setiap lambda dengan jenis: jika dalam f xjenis fdiketahui, maka xdiperiksa terhadap jenis argumen yang fditerima alih-alih disimpulkan dan dibandingkan untuk kesetaraan (yang juga kurang efisien). Tetapi jika flambda, itu membutuhkan penjelasan jenis eksplisit (penjelasan dihilangkan dalam tata bahasa dan di mana-mana, Anda dapat menambahkan Ann Term Termatau λ' (σ : Term) (v : Var)ke konstruktor).

Juga, lihat Simpler, Lebih Mudah! blogpost.

Mari kita mulai. Saya tidak akan peduli dengan paradoks Girard, karena mengalihkan perhatian dari ide-ide sentral. Saya perlu memperkenalkan beberapa mesin presentasi tentang penilaian dan derivasi dan semacamnya.

Tatabahasa

Term :: = (Elim) | * | (Var: Term) → Term | λVar↦Term

Elim :: = Istilah: Istilah | Var | Istilah Elim

Tata bahasanya memiliki dua bentuk yang saling didefinisikan, "istilah" yang merupakan gagasan umum tentang benda (jenis adalah benda, nilai adalah benda), termasuk * (jenis jenis), jenis fungsi dependen, dan abstraksi lambda, tetapi juga menanamkan " eliminasi "(yaitu" penggunaan "daripada" konstruksi "), yang merupakan aplikasi bersarang di mana hal yang pada akhirnya di posisi fungsi adalah variabel atau istilah yang dijelaskan dengan tipenya.

Aturan Pengurangan

(λy↦t: (x: S) → T) s ↝ t [s: S / y]: T [s: S / x]

(t: T) ↝ t

Operasi substitusi t [e / x] menggantikan setiap kemunculan variabel x dengan eliminasi e, menghindari penangkapan nama. Untuk membentuk aplikasi yang dapat mengurangi, istilah lambda harus dianotasi berdasarkan jenisnya untuk melakukan eliminasi . Anotasi jenis ini memberikan abstraksi lambda semacam "reaktivitas", yang memungkinkan aplikasi untuk melanjutkan. Setelah kami mencapai titik di mana tidak ada lagi aplikasi yang terjadi dan t: T sedang disematkan kembali ke dalam sintaksis istilah, kita dapat menghapus anotasi jenis.

Mari kita memperluas hubungan ↝ reduksi dengan penutupan struktural: aturan berlaku di mana saja di dalam istilah dan eliminasi bahwa Anda dapat menemukan sesuatu yang cocok dengan sisi kiri. Tulis ↝ * untuk penutupan refleksif-transitif (0-atau-lebih-langkah) dari ↝. Sistem reduksi yang dihasilkan bersatu dalam pengertian ini:

Jika s ↝ * p dan s ↝ * q, maka ada beberapa r sehingga p ↝ * r dan q ↝ * r.

Konteks

Konteks :: = | Konteks, Var: Istilah

Konteks adalah urutan yang menetapkan jenis ke variabel, tumbuh di sebelah kanan, yang kita anggap sebagai "lokal", memberi tahu kita tentang variabel terikat terbaru. Properti penting dari konteks adalah bahwa selalu mungkin untuk memilih variabel yang belum digunakan dalam konteks. Kami mempertahankan invarian bahwa variabel yang dianggap sebagai tipe dalam konteks berbeda.

Penghakiman

Penghakiman :: = Konteks ⊢ Term memiliki Term | Konteks ⊢ Elim is Term

Itu tata bahasa penilaian, tetapi bagaimana cara membacanya? Sebagai permulaan, ⊢ adalah simbol "turnstile" tradisional, memisahkan asumsi dari kesimpulan: Anda dapat membacanya secara informal sebagai "berkata".

G ⊢ T memiliki t

berarti konteks yang diberikan G, tipe T mengakui istilah t;

G ⊢ e adalah S

berarti bahwa diberikan konteks G, eliminasi e diberikan tipe S.

Penilaian memiliki struktur yang menarik: nol atau lebih input , satu subjek atau lebih , nol atau lebih output .

INPUTS                   SUBJECT        OUTPUTS
Context |- Term   has    Term
Context |-               Elim      is   Term

Artinya, kita harus mengusulkan jenis-jenis istilah terlebih dahulu dan cukup memeriksanya , tetapi kita mensintesiskan jenis-jenis eliminasi.

Aturan Mengetik

Saya menyajikan ini dalam gaya Prolog yang samar-samar, menulis J -: P1; ...; Pn untuk menunjukkan bahwa penilaian J berlaku jika premis P1 hingga Pn juga berlaku. Premis akan menjadi penilaian lain, atau klaim tentang pengurangan.

Ketentuan

G ⊢ T memiliki t -: T ↝ R; G ⊢ R memiliki t

G ⊢ * memiliki *

G ⊢ * memiliki (x: S) → T -: G ⊢ * memiliki S; G, z: S! - * memiliki T [z / x]

G ⊢ (x: S) → T memiliki λy↦t -: G, z: S ⊢ T [z / x] memiliki t [z / y]

G ⊢ T memiliki (e) -: G ⊢ e adalah T

Eliminasi

G ⊢ e adalah R -: G ⊢ e adalah S; S ↝ R

G, x: S, G '⊢ x adalah S

G ⊢ fs adalah T [s: S / x] -: G ⊢ f adalah (x: S) → T; G ⊢ S memiliki s

Dan itu dia!

Hanya dua aturan yang tidak diarahkan sintaks: aturan yang mengatakan "Anda bisa mengurangi tipe sebelum Anda menggunakannya untuk memeriksa istilah" dan aturan yang mengatakan "Anda bisa mengurangi tipe setelah Anda mensintesisnya dari eliminasi". Salah satu strategi yang dapat dilakukan adalah mengurangi tipe hingga Anda mengekspos konstruktor paling atas.

Sistem ini tidak sangat normal (karena Paradox Girard, yang merupakan paradoks referensi diri pembohong), tetapi dapat dibuat sangat normal dengan memecah * menjadi "level alam semesta" di mana setiap nilai yang melibatkan tipe di level bawah sendiri memiliki tipe pada level yang lebih tinggi, mencegah referensi diri.

Sistem ini, bagaimanapun, memiliki sifat pelestarian tipe, dalam pengertian ini.

Jika G ⊢ T memiliki t dan G ↝ * D dan T ↝ * R dan t ↝ r, maka D ⊢ R memiliki r.

Jika G ⊢ e adalah S dan G ↝ * D dan e ↝ f, maka ada R sehingga S ↝ * R dan D ⊢ f adalah R.

Konteks dapat menghitung dengan membiarkan istilah yang dikandungnya menghitung. Artinya, jika penilaian sekarang valid, Anda dapat menghitung inputnya sebanyak yang Anda suka dan subjeknya satu langkah, dan kemudian dimungkinkan untuk menghitung hasilnya entah bagaimana untuk memastikan penilaian yang dihasilkan tetap valid. Buktinya adalah induksi sederhana pada derivasi mengetik, mengingat pertemuan -> *.

Tentu saja, saya hanya menyajikan inti fungsional di sini, tetapi ekstensi bisa sangat modular. Berikut ini adalah pasangan.

Term :: = ... | (x: S) * T | s, t

Elim :: = ... | e.head | e.tail

(s, t: (x: S) * T) .head ↝ s: S

(s, t: (x: S) * T) .tail ↝ t: T [s: S / x]

G ⊢ * memiliki (x: S) * T -: G ⊢ * memiliki S; G, z: S ⊢ * memiliki T [z / x]

G ⊢ (x: S) * T memiliki s, t -: G ⊢ S memiliki s; G ⊢ T [s: S / x] memiliki t

G ⊢ e.head adalah S -: G ⊢ e adalah (x: S) * T

G ⊢ e.tail adalah T [e.head / x] -: G ⊢ e is (x: S) * T

Korespondensi Curry-Howard mengatakan bahwa ada korespondensi sistematis antara sistem tipe dan sistem bukti dalam logika. Mengambil pandangan programmer-centric ini, Anda bisa menyusunnya kembali dengan cara ini:

• Sistem bukti logis adalah bahasa pemrograman.
• Bahasa-bahasa ini diketik secara statis.
• Jenis tanggung jawab sistem dalam bahasa seperti itu adalah untuk melarang program yang akan membangun bukti tidak sehat.

Terlihat dari sudut ini:

• Kalkulus lambda yang tidak diketik yang Anda simpulkan tidak memiliki sistem tipe yang signifikan, jadi sistem bukti yang dibangun di atasnya akan tidak sehat.
• Kalkulus lambda yang diketik sederhana adalah bahasa pemrograman yang memiliki semua jenis yang diperlukan untuk membangun bukti suara dalam logika sentensial ("jika / kemudian", "dan", "atau", "atau", "tidak"). Tetapi tipenya tidak cukup baik untuk memeriksa bukti yang melibatkan bilangan bulat ("untuk semua x, ..."; "terdapat x sedemikian rupa sehingga ...").
• Kalkulus lambda yang diketik secara akurat memiliki tipe dan aturan yang mendukung logika sentensial dan quantifiers tingkat pertama (kuantifikasi atas nilai).

Berikut adalah aturan deduksi alami untuk logika tingkat pertama, menggunakan diagram dari entri Wikipedia tentang deduksi alami . Ini pada dasarnya adalah aturan dari kalkulus lambda mengetik minimal juga.

Perhatikan bahwa aturan memiliki ketentuan lambda di dalamnya. Ini dapat dibaca sebagai program yang membangun bukti dari kalimat yang diwakili oleh tipenya (atau lebih tepatnya, kami hanya mengatakan program adalah bukti ). Aturan pengurangan yang serupa yang Anda berikan dapat diterapkan pada persyaratan lambda ini.

Kenapa kita peduli dengan ini? Yah, pertama-tama, karena bukti mungkin berubah menjadi alat yang berguna dalam pemrograman, dan memiliki bahasa yang dapat bekerja dengan bukti sebagai objek kelas satu membuka banyak jalan. Misalnya, jika fungsi Anda memiliki prasyarat, alih-alih menuliskannya sebagai komentar, Anda sebenarnya dapat meminta bukti sebagai argumen.

Kedua, karena jenis mesin sistem yang diperlukan untuk menangani bilangan bulat mungkin memiliki kegunaan lain dalam konteks pemrograman. Secara khusus, bahasa yang diketik secara dependen menangani universal quantifiers ("for all x, ...") dengan menggunakan konsep yang disebut tipe fungsi dependen — fungsi di mana tipe statis hasil dapat bergantung pada nilai runtime argumen.

Untuk memberikan aplikasi yang sangat pejalan kaki ini, saya menulis kode sepanjang waktu yang harus membaca file Avro yang terdiri dari catatan dengan struktur yang seragam — semua berbagi set nama dan tipe bidang yang sama. Ini mengharuskan saya untuk:

1. Hardcode struktur catatan dalam program sebagai tipe catatan.
   • Keuntungan: Kode lebih sederhana dan kompiler dapat menangkap kesalahan dalam kode saya
   • Kerugian: Program ini hardcoded untuk membaca file yang sesuai dengan tipe catatan.
2. Baca skema data saat runtime, perlihatkan secara umum sebagai struktur data, dan gunakan itu untuk memproses catatan secara umum
   • Keuntungan: Program saya bukan hardcoded untuk hanya satu jenis file
   • Kekurangan: Kompilator tidak dapat menangkap banyak kesalahan.

Seperti yang dapat Anda lihat di halaman tutorial Avro Java , mereka menunjukkan kepada Anda bagaimana menggunakan perpustakaan sesuai dengan kedua pendekatan ini.

Dengan tipe fungsi dependen Anda dapat memiliki kue dan memakannya, dengan biaya sistem tipe yang lebih kompleks. Anda bisa menulis fungsi yang membaca file Avro, mengekstrak skema, dan mengembalikan konten file sebagai aliran catatan yang jenis statis tergantung pada skema yang disimpan dalam file . Kompiler akan dapat menangkap kesalahan di mana saya, misalnya, mencoba mengakses bidang bernama yang mungkin tidak ada dalam catatan file yang akan diproses saat runtime. Manis ya