Coq가 핵심 언어로 let-expression을 포함하는 이유

Coq는 핵심 언어로 let-expression을 포함합니다. let 표현식을 다음과 같은 애플리케이션으로 변환 할 수 있습니다 . typechecking 때 let x : t = v in b ~> (\(x:t). b) v 값 v을 사용할 수 없기 때문에 항상 작동하지는 않습니다 b. 그러나 이는 특수한 형태의 응용 분야에 대한 유형 검사를 통해 쉽게 해결할 수 있습니다 (\(x:t). b) v. 이를 통해 유형 검사 중에 특수한 경우를 제외하고 let-expression을 제거 할 수 있습니다. 왜 Coq에 여전히 let-expressions가 포함됩니까? 특별한 장점이없는 것 외에 다른 장점이 있습니까?

let표현을 응용 프로그램으로 번역 할 수 있다는 것은 일반적인 오해입니다 . 의 차이 let x : t := b in v와는 (fun x : t => v) b에서이다 let의 -expression,시 유형 검사 v우리가 알고있는 x동일 b하지만, 응용 프로그램에서 우리는 (서브 표현식은하지 않는 fun x : t => v그 자체로 이해한다).

예를 들면 다음과 같습니다.

(* 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).

응용 프로그램 (fun x : t => v) b을 특별한 경우 로 만들 겠다는 제안 은 실제로 효과가 없습니다. 더 신중하게 생각합시다.

예를 들어, 위의 예를 계속 진행하여이 문제를 어떻게 처리 하시겠습니까?

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

a입력 할 수 없기 때문에 아마도 작동 하지 않지만 정의를 펼치면 잘 입력 된 표현이 나타납니다. 사용자가 우리를 사랑하거나 디자인 결정을 미워한다고 생각하십니까?

"특별한 경우"를 갖는 것이 무엇을 의미하는지 신중하게 생각해야합니다. 응용 프로그램이 있으면 -abstraction 인지 확인하기 전에 e₁ e₂정규화해야 합니까? 그렇다면 잘못된 유형의 표현식을 정규화하고 순환 할 수 있음을 의미합니다. 그렇지 않다면 제안서의 유용성이 의심스러워 보입니다.e₁$\lambda$

또한 잘 정리 된 표현의 모든 하위 표현이 잘 정리되어 있다고 말하는 기본 정리를 깨뜨릴 수 있습니다. nullJava에 도입하는 것만 큼 합리적 입니다.