Perché Coq include espressioni let nel suo linguaggio principale

Coq include espressioni let nel suo linguaggio principale. Siamo in grado di tradurre le espressioni let in applicazioni come questa: let x : t = v in b ~> (\(x:t). b) v capisco che ciò non funziona sempre perché il valore vnon sarebbe disponibile quando si esegue il controllo dei caratteri b. Tuttavia, ciò può essere facilmente risolto mediante un involucro speciale per il controllo dei tipi di applicazioni del modulo (\(x:t). b) v. Questo ci consente di rimuovere le espressioni let al costo di un caso speciale durante il controllo del tipo. Perché Coq include include ancora let-expressions? Hanno altri vantaggi (oltre a non aver bisogno del caso speciale)?

È letun'idea sbagliata comune che possiamo tradurre -espressioni in applicazioni. La differenza tra let x : t := b in ve (fun x : t => v) bè che letnell'espressione, durante la verifica del tipo di vsappiamo che xè uguale a b, ma nell'applicazione non lo facciamo (la sottoespressione fun x : t => vdeve avere senso da sola).

Ecco un esempio:

(* Dependent type of vectors. *)
Inductive Vector {A : Type} : nat -> Type :=
  | nil : Vector 0
  | cons : forall n, A -> Vector n -> Vector (S n).

(* This works. *)
Check (let n := 0 in cons n 42 nil).

(* This fails. *)
Check ((fun (n : nat) => cons n 42 nil) 0).

Il tuo suggerimento di rendere l'applicazione (fun x : t => v) bun caso speciale non funziona davvero. Pensiamoci più attentamente.

Ad esempio, come gestiresti questo, continuando l'esempio sopra?

Definition a := (fun (n : nat) => cons n 42 nil).
Check a 0.

Presumibilmente questo non funzionerà perché anon può essere digitato, ma se spieghiamo la sua definizione, otteniamo un'espressione ben digitata. Pensi che gli utenti ci ameranno o ci odieranno per la nostra decisione di progettazione?

Devi pensare attentamente cosa significa avere il "caso speciale". Se ho un'applicazione e₁ e₂, dovrei normalizzarmi e₁prima di decidere se si tratta di una -abstraction? In caso affermativo, ciò significa che normalizzerò espressioni mal digitate e che potrebbero scorrere. In caso contrario, l'usabilità della tua proposta sembra discutibile.$\lambda$

Si romperebbe anche il teorema fondamentale secondo cui ogni sottoespressione di un'espressione ben tipizzata è ben tipizzata. È sensato quanto introdurlo nullin Java.