Nông cạn so với nhúng sâu

Khi mã hóa logic thành một trợ lý chứng minh như Coq hoặc Isabelle, một sự lựa chọn cần phải được thực hiện giữa việc sử dụng nông và nhúng sâu . Trong một công thức logic nhúng nhúng nông được viết trực tiếp trong logic của câu tục ngữ định lý, trong khi đó trong các công thức logic nhúng sâu được biểu diễn dưới dạng kiểu dữ liệu.

• Những lợi thế và hạn chế của các phương pháp khác nhau là gì?
• Có bất kỳ hướng dẫn có sẵn để xác định sử dụng?
• Có thể chuyển đổi giữa hai đại diện theo bất kỳ hệ thống nào?

Để tạo động lực, tôi muốn mã hóa các logic liên quan đến bảo mật khác nhau vào Coq và đang tự hỏi những ưu và nhược điểm của các phương pháp khác nhau là gì.

Những lợi thế và hạn chế của các phương pháp khác nhau là gì?

• Ưu điểm của nhúng sâu: Bạn có thể chứng minh và xác định mọi thứ bằng cách cảm ứng trên cấu trúc của công thức. Ví dụ về lợi ích là kích thước của một công thức.

• Nhược điểm của các nhúng sâu: Bạn đã xử lý rõ ràng với ràng buộc của các biến. Điều đó thường rất tốn công.

Có bất kỳ hướng dẫn có sẵn để xác định sử dụng?

Các nhúng nông rất hữu ích để nhập kết quả đã được chứng minh trong logic đối tượng. Ví dụ, nếu bạn đã chứng minh một cái gì đó trong một logic nhỏ (ví dụ logic phân tách), các nhúng nhúng nông có thể là một công cụ được lựa chọn để nhập kết quả của bạn vào Coq.

Mặt khác, việc nhúng sâu gần như là bắt buộc khi bạn muốn chứng minh các định lý meta về logic đối tượng (ví dụ như loại bỏ cắt).

Có thể chuyển đổi giữa hai đại diện theo bất kỳ hệ thống nào?

Ý tưởng đằng sau việc nhúng nông thực sự là làm việc trực tiếp trong một mô hình của các công thức đối tượng. Thông thường mọi người sẽ ánh xạ trực tiếp một công thức đối tượng P (sử dụng các ký hiệu hoặc bằng cách dịch bằng tay) cho một cư dân của Prop. Tất nhiên, có những cư dân của Prop không thể có được bằng cách nhúng một công thức của logic đối tượng. Do đó, bạn mất một số loại hoàn chỉnh.

Vì vậy, có thể gửi mọi kết quả thu được trong cài đặt nhúng sâu thông qua chức năng diễn giải.

Dưới đây là một ví dụ coq nhỏ:

Công thức quy nạp: Đặt: =
    Ftrue: công thức
  | Ffalse: công thức
  | Fand: công thức -> công thức -> công thức
  | Cho: công thức -> công thức -> công thức.

Diễn giải Fixpoint (F: công thức): Prop: = khớp F với 
    Ftrue => Đúng
  | Ffalse => Sai
  | Fand ab => (giải thích a) / \ (giải thích b)
  | Với ab => (giải thích a) \ / (giải thích b)
 kết thúc.

Đạo hàm quy nạp: công thức -> Prop: = 
    deep_axiom: Ftrue có thể dẫn xuất
  | deep_and: forall ab, derivable a -> derivable b -> derivable (Fand ab)
  | deep_or1: forall ab, derivable a -> derivable (For ab)
  | deep_or2: forall ab, derivable b -> derivable (For ab).

Sderivable cảm ứng: Prop -> Prop: = 
    nông_axiom: sderivable Đúng 
  | nông_and: forall ab, sderivable a -> sderivable b -> sderivable (a / \ b)
  | nông_or1: forall ab, sderivable a -> sderivable (a \ / b)
  | nông_or2: forall ab, sderivable b -> sderivable (a \ / b).

(* Bạn có thể chứng minh bổ đề sau: *)
Bổ đề nông: 
   forall F, derivable F -> sderivable (giải thích F).

(* Bạn KHÔNG thể chứng minh bổ đề sau: *)
Bổ đề t: 
   forall P, sderivable P -> tồn tại F, giải thích F = P.

Nói một cách đơn giản, với sự nhúng sâu vào logic, bạn (1) xác định một kiểu dữ liệu biểu thị cú pháp cho logic của bạn và (2) đưa ra một mô hình cú pháp và (3) chứng minh rằng các tiên đề về cú pháp của bạn là âm thanh đối với đến mô hình. Với cách nhúng nông, bạn bỏ qua các bước (1) và (2), và chỉ bắt đầu với một mô hình và chứng minh sự ràng buộc giữa các công thức. Điều này có nghĩa là các nhúng nhúng thường ít hoạt động hơn để lên khỏi mặt đất, vì chúng đại diện cho công việc mà bạn thường kết thúc bằng cách nhúng sâu.

Tuy nhiên, nếu có một sự nhúng sâu, thường sẽ dễ dàng hơn để viết các thủ tục quyết định phản ánh, vì bạn đang làm việc với các công thức thực sự có cú pháp mà bạn có thể lặp lại. Ngoài ra, nếu mô hình của bạn lạ hoặc phức tạp, thì bạn thường không muốn làm việc trực tiếp với ngữ nghĩa. (Ví dụ: nếu bạn sử dụng tính đa dạng sinh học để buộc đóng cửa có thể chấp nhận được hoặc sử dụng các mô hình kiểu Kripke để buộc các thuộc tính khung trong logic tách biệt hoặc các trò chơi tương tự.) Tuy nhiên, việc nhúng sâu gần như chắc chắn sẽ khiến bạn phải suy nghĩ rất nhiều về sự ràng buộc và thay thế thay đổi , điều này sẽ lấp đầy trái tim bạn bằng cơn thịnh nộ, vì đây là (a) tầm thường, và (b) là nguồn phiền toái không bao giờ kết thúc.

Trình tự chính xác bạn nên thực hiện là: (1) cố gắng thực hiện bằng cách nhúng nông. (2) Khi hết hơi, hãy thử sử dụng chiến thuật và báo giá để chạy các quy trình quyết định bạn muốn chạy. (3) Nếu điều đó cũng hết hơi, hãy từ bỏ và sử dụng cú pháp gõ phụ thuộc để nhúng sâu.

• Lên kế hoạch mất vài tháng vào (3) nếu đây là lần đầu tiên bạn ra ngoài. Bạn sẽ cần phải làm quen với các tính năng ưa thích của trợ lý bằng chứng của bạn để tỉnh táo. (Nhưng đây là một khoản đầu tư sẽ trả hết nói chung.)
• Nếu trợ lý chứng minh của bạn không có loại phụ thuộc, hãy ở cấp 2.
• Nếu ngôn ngữ đối tượng của bạn được gõ một cách phụ thuộc, hãy ở cấp 2.

Ngoài ra, đừng cố gắng đi dần lên thang. Khi bạn quyết định đi lên thang phức tạp, hãy thực hiện một bước đầy đủ tại một thời điểm. Nếu bạn làm từng chút một, thì bạn sẽ nhận được rất nhiều định lý kỳ lạ và không thể sử dụng được (ví dụ: bạn sẽ nhận được nhiều cú pháp nửa khẳng định và các định lý pha trộn cú pháp và ngữ nghĩa theo những cách lạ), mà bạn sẽ cuối cùng phải vứt đi.

EDIT: Đây là một nhận xét giải thích lý do tại sao đi lên thang dần dần rất hấp dẫn và tại sao nó dẫn (nói chung) dẫn đến đau khổ.

$A \star B$$I$$A \star B \iff B \star A$$(A \star B) \star C \iff A \star (B \star C)$$(I \star A) \star (B \star C)$$A \star (B \star (C \star I))$

$\star$

Đây là sự thật, và hoạt động! Tuy nhiên, lưu ý rằng sự kết hợp cũng là ACUI và sự khác biệt cũng vậy. Vì vậy, bạn sẽ trải qua quá trình tương tự trong các bằng chứng khác, với các kiểu dữ liệu danh sách khác nhau và sau đó bạn sẽ có ba cú pháp cho các đoạn logic phân tách khác nhau và chắc chắn bạn sẽ có các tiện ích cho mỗi trong số chúng, chắc chắn sẽ khác nhau, và bạn sẽ thấy mình muốn có một meteditorem mà bạn đã chứng minh để tách kết hợp cho sự khác biệt, và sau đó bạn sẽ muốn trộn các cú pháp, và sau đó bạn sẽ phát điên.

Tốt hơn là nhắm mục tiêu mảnh lớn nhất mà bạn có thể xử lý với một nỗ lực hợp lý và chỉ cần làm điều đó.

Điều quan trọng là phải hiểu rằng có một phổ từ sâu đến nông. Bạn mô hình hóa các phần của ngôn ngữ của bạn một cách sâu sắc bằng cách nào đó nên tham gia vào một số lập luận quy nạp về việc xây dựng ngôn ngữ đó, phần còn lại tốt hơn là nhìn vào ngữ nghĩa trực tiếp của chất nền của logic.

Ví dụ, khi bạn muốn suy luận về Hoare Logic, bạn có thể mô hình hóa ngôn ngữ biểu thức một cách nông cạn, nhưng phác thảo của ngôn ngữ gán-if-while phải là một kiểu dữ liệu cụ thể. Bạn không cần nhập cấu trúc của x + y hoặc <b, nhưng bạn cần phải làm việc với, whilev.v.

Trong các câu trả lời khác, có những ám chỉ đến các loại phụ thuộc. Điều này nhắc nhở về vấn đề cổ xưa để thể hiện các ngôn ngữ với các chất kết dính một cách lành mạnh, sao cho chúng nông cạn nhất có thể, nhưng vẫn thừa nhận một số lập luận quy nạp. Ấn tượng của tôi là bồi thẩm đoàn vẫn ra phán xét về tất cả các phương pháp và bài báo khác nhau đã xuất hiện trong 10-20 năm qua về chủ đề đó. "Thách thức POPLmark" đối với các cộng đồng trợ lý chứng minh khác nhau cũng ở một mức độ nào đó.

Điều kỳ lạ là, trong HOL cổ điển không có kiểu phụ thuộc, cách tiếp cận HOL-Nominal của C. Urban hoạt động khá tốt cho sự ràng buộc nông cạn, mặc dù nó không theo kịp sự thay đổi văn hóa trong các cộng đồng chính thức hóa ngôn ngữ lập trình này.