เหตุใด Coq จึงรวมเอาการแสดงออกมาเป็นภาษาหลัก

Coq รวมถึงการแสดงออกให้เป็นภาษาหลักของมัน เราสามารถแปลการแสดงออกให้กับแอพพลิเคชั่นเช่นนี้: let x : t = v in b ~> (\(x:t). b) v ฉันเข้าใจว่ามันไม่ได้ผลเสมอไปเพราะค่าvจะไม่สามารถใช้ได้เมื่อพิมพ์แบบตรวจbสอบ อย่างไรก็ตามเรื่องนี้สามารถแก้ไขได้อย่างง่ายดายโดยปลอกพิเศษ typechecking (\(x:t). b) vของการใช้งานของฟอร์ม สิ่งนี้ช่วยให้เราสามารถลบการแสดงออกในราคาพิเศษในขณะพิมพ์ เหตุใด Coq จึงรวมถึงให้รวมการแสดงออก? พวกเขามีข้อได้เปรียบอื่น ๆ (นอกเหนือจากไม่จำเป็นต้องใช้กรณีพิเศษ)?

มันเป็นความเข้าใจผิดที่พบบ่อยซึ่งเราสามารถแปลlet-Expresions ไปยังแอปพลิเคชัน ความแตกต่างระหว่างlet x : t := b in vและ(fun x : t => v) bคือในlet-expression ในระหว่างการตรวจสอบชนิดของvเรารู้ว่าxมีค่าเท่ากับbแต่ในแอปพลิเคชันที่เราทำไม่ได้ (subexpression 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ไม่สามารถพิมพ์ได้ แต่ถ้าเราเปิดเผยคำจำกัดความเราจะได้รับนิพจน์ที่พิมพ์ได้ดี คุณคิดว่าผู้ใช้จะรักเราหรือเกลียดเราในการตัดสินใจออกแบบของเราหรือไม่?

คุณต้องคิดให้ถี่ถ้วนว่าการมี "กรณีพิเศษ" หมายความว่าอย่างไร หากฉันมีแอปพลิเคชันe₁ e₂ฉันควรทำให้เป็นมาตรฐานe₁ก่อนที่จะตัดสินใจว่าเป็นแอปพลิเคชันหรือไม่$\lambda$-abstraction? ถ้าใช่นี่หมายความว่าฉันจะทำให้นิพจน์ที่พิมพ์ผิดกลับคืนมาและสิ่งเหล่านั้นอาจวนซ้ำ หากไม่มีการใช้งานข้อเสนอของคุณน่าสงสัย

คุณจะทำลายทฤษฏีพื้นฐานที่บอกว่านิพจน์ย่อยที่พิมพ์ได้ดีนั้นถูกพิมพ์ออกมาอย่างดี มันมีเหตุผลพอ ๆ กับการแนะนำให้รู้จักnullกับจาวา