Các kỹ thuật chứng minh cho thấy việc kiểm tra loại phụ thuộc là có thể quyết định


10

Tôi đang ở trong một tình huống mà tôi cần phải chứng minh rằng việc đánh máy là có thể quyết định đối với một phép tính phụ thuộc mà tôi đang làm việc. Cho đến nay, tôi đã có thể chứng minh rằng hệ thống đang bình thường hóa mạnh mẽ, và do đó, sự bình đẳng xác định là có thể quyết định.

Trong nhiều tài liệu tham khảo tôi đọc, tính quyết định của việc đánh máy được liệt kê là hệ quả của sự bình thường hóa mạnh mẽ và tôi tin rằng trong những trường hợp đó, nhưng tôi tự hỏi làm thế nào một người thực sự thể hiện điều này.

Cụ thể, tôi bị mắc kẹt như sau:

  • Chỉ vì các thuật ngữ được gõ tốt đang bình thường hóa mạnh mẽ, điều đó không có nghĩa là thuật toán sẽ không lặp lại mãi mãi trên các đầu vào không được gõ tốt
  • Vì các mối quan hệ logic thường được sử dụng để hiển thị chuẩn hóa mạnh mẽ, không có số liệu giảm thuận tiện khi chúng tôi tiến hành các thuật ngữ đánh máy. Vì vậy, ngay cả khi các quy tắc loại của tôi được định hướng theo cú pháp, không có gì đảm bảo rằng việc áp dụng các quy tắc cuối cùng sẽ chấm dứt.

Tôi đang tự hỏi, có ai có một tài liệu tham khảo tốt về một bằng chứng về tính quyết định của việc đánh máy cho một ngôn ngữ được gõ phụ thuộc không? Nếu đó là một phép tính cốt lõi nhỏ, thì tốt thôi. Bất cứ điều gì thảo luận về các kỹ thuật bằng chứng cho thấy sự quyết đoán sẽ là tuyệt vời.


7
Các thuật toán kiểm tra loại hai chiều thông thường không bao giờ cố gắng bình thường hóa một thuật ngữ (hoặc một loại) mà không kiểm tra trước rằng nó được gõ tốt (hoặc được định dạng tốt). Bạn không cần phải lo lắng về việc bình thường hóa các điều khoản chưa được kiểm tra.
Andrej Bauer

7
Về việc áp dụng các quy tắc: tất cả các quy tắc thuật ngữ và loại làm giảm mục tiêu, ngoại trừ chuyển đổi loại. Do đó, chúng ta cần kiểm soát chuyển đổi loại, điều chúng ta làm bằng cách sử dụng phương pháp hai chiều.
Andrej Bauer

Câu trả lời:


9

Thực sự có một sự tinh tế ở đây, mặc dù mọi thứ hoạt động tốt trong trường hợp kiểm tra kiểu. Tôi sẽ viết ra vấn đề ở đây, vì nó dường như xuất hiện trong nhiều chủ đề liên quan và cố gắng giải thích lý do tại sao mọi thứ đều ổn khi kiểm tra kiểu trong lý thuyết loại phụ thuộc "tiêu chuẩn" (tôi sẽ mơ hồ, vì những vấn đề này có xu hướng tăng lên bất kể):

Sự thật 1: Nếu là một dẫn xuất của , thì có một đạo hàm của cho một số loại và cho mọi subterm , có một số loại , một bối cảnh và một nguồn gốc của .DΓt:ADΓA:ssutBΔDΔu:B

Thực tế tốt đẹp này có phần khó chứng minh và được bù đắp bởi một thực tế khá khó chịu:

Sự thật 2: Nói chung, và không phải là đạo hàm phụ của !DD D

Điều này phụ thuộc một chút vào công thức chính xác của hệ thống loại của bạn, nhưng hầu hết các hệ thống "vận hành" được triển khai trong thực tế đều đáp ứng Sự thật 2.

Điều này có nghĩa là bạn không thể "chuyển sang các thuật ngữ phụ" khi suy luận bằng cách cảm ứng trên các đạo hàm hoặc kết luận rằng tuyên bố quy nạp là đúng về loại thuật ngữ bạn đang cố gắng chứng minh điều gì đó.

Thực tế này đã cắn bạn khá gay gắt khi cố gắng chứng minh những tuyên bố dường như vô hại, ví dụ: các hệ thống có chuyển đổi được gõ tương đương với các hệ thống có chuyển đổi chưa được gõ.

Tuy nhiên , trong trường hợp suy luận kiểu, bạn có thể đưa ra thuật toán suy luận loại và loại đồng thời (loại của loại) bằng cách cảm ứng trên cấu trúc của thuật ngữ, có thể liên quan đến thuật toán định hướng kiểu như Andrej gợi ý. Đối với một thuật ngữ đã cho (và bối cảnh , bạn sẽ thất bại hoặc tìm sao cho và . Bạn không cần sử dụng giả thuyết quy nạp để tìm ra giả thuyết sau phái sinh, và đặc biệt là bạn tránh được vấn đề được giải thích ở trên.tΓA,sΓt:AΓA:s

Trường hợp quan trọng (và trường hợp duy nhất thực sự cần chuyển đổi) là ứng dụng:

infer(t u):
   type_t, sort_t <- infer(t)
   type_t' <- normalize(type_t)
   type_u, sort_u <- infer(u)
   type_u' <- normalize(type_u)
   if (type_t' = Pi(A, B) and type_u' = A' and alpha_equal(A, A') then
      return B, sort_t (or the appropriate sort)
   else fail

Mọi lời kêu gọi bình thường hóa đều được thực hiện theo các điều khoản được đánh máy tốt, vì đây là bất biến cho inferthành công của.


Nhân tiện, khi nó được triển khai, Coq không có kiểm tra loại có thể quyết định, vì nó bình thường hóa phần thân của các fixcâu lệnh trước khi thử gõ chúng.

Ở mức độ nào, các giới hạn về các hình thức bình thường của các thuật ngữ được đánh máy tốt là rất thiên văn, rằng định lý về tính quyết định chủ yếu là học thuật vào thời điểm này. Trong thực tế, bạn chạy thuật toán kiểm tra loại miễn là bạn có kiên nhẫn và thử một tuyến đường khác nếu nó chưa kết thúc trước đó.


Tôi thấy câu trả lời của bạn rất hữu ích, cảm ơn bạn. Tôi có hai câu hỏi: 1. "Hệ thống vận hành" nghĩa là gì? Cái gì thay thế? 2. Bạn có thể rõ ràng hơn với ví dụ: ý nghĩa của nó (thực tế là chúng ta đang cố chứng minh điều gì không?) "Các hệ thống có chuyển đổi được gõ tương đương với các hệ thống có chuyển đổi chưa được gõ."? Cảm ơn!
Łukasz Lew

1
@ UkaszLew Thay thế cho một hệ điều hành (một hệ thống được triển khai trong thực tế, ví dụ như phần mềm Coq hoặc Agda) sẽ là một hệ thống lý thuyết, rất hữu ích để chứng minh các tính chất siêu lý thuyết, nhưng không hiệu quả hoặc bất tiện khi sử dụng trong thực tế. Chứng minh sự tương đương của một hệ thống vận hành và lý thuyết thường là một phần quan trọng của thiết kế hệ thống. Tôi nói thêm về điều này ở đây: cstheory.stackexchange.com/a/41457/3984
cody

Tôi nghĩ rằng đáng để đề cập đến Đơn giản hơn của Lennart Augowersson , Dễ dàng hơn! . Đây là một triển khai Haskell tối thiểu của kiểm tra loại và một số suy luận cho phép tính lambda phụ thuộc. Có mã tương ứng chặt chẽ với cody infer(t u):; để tìm nó, tìm kiếm " tCheck r (App f a) =". Để thực hiện đầy đủ hơn nhưng vẫn đơn giản, bạn có thể kiểm tra MortetypeWith .
Łukasz Lew

1
@ UkaszLew Vấn đề chuyển đổi được gõ và không được gõ là một câu hỏi mở nổi tiếng liên quan đến 2 công thức của lý thuyết loại và đã được giải quyết gần đây: pauillac.inria.fr/~herbelin/articles/ tựa
cody

Những gì hiện nó có nghĩa ? ut
jonaprieto
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.