Mối quan hệ giữa lý thuyết loại Russell và hệ thống loại


12

Gần đây tôi nhận ra rằng có một số loại quan hệ giữa lý thuyết loại Russell và hệ thống loại, như được tìm thấy, ví dụ như trong Haskell. Trên thực tế, một số ký hiệu cho các loại trong Haskell dường như có tiền thân trong lý thuyết loại. Nhưng, IMHO, động lực của Russell vào năm 1908 là để tránh nghịch lý của Russell và tôi không chắc điều đó có liên quan đến các hệ thống loại trong khoa học máy tính như thế nào.

Nghịch lý của Russell ở dạng này hay dạng khác là điều mà chúng ta sẽ phải lo lắng, ví dụ, nếu chúng ta không có một hệ thống loại tốt trong một ngôn ngữ nhất định?

Câu trả lời:


8

"Lý thuyết loại" theo nghĩa ngôn ngữ lập trình và theo nghĩa của Russell có liên quan chặt chẽ với nhau. Trên thực tế, lĩnh vực hiện đại của lý thuyết loại phụ thuộc nhằm cung cấp nền tảng xây dựng cho toán học. Không giống như lý thuyết tập hợp, hầu hết nghiên cứu về lý thuyết loại toán học được thực hiện trong các trợ lý chứng minh như Coq, NuPRL hoặc Agda. Như vậy, bằng chứng được thực hiện trong các hệ thống này không chỉ "chính thức hóa" mà còn thực sự chính thức và kiểm tra máy móc. Sử dụng chiến thuật và các kỹ thuật tự động hóa bằng chứng khác mà chúng tôi cố gắng chứng minh hệ thống "cấp độ cao" và do đó giống với toán học không chính thức, nhưng vì mọi thứ đều được kiểm tra nên chúng tôi có sự đảm bảo tốt hơn nhiều về tính đúng đắn.

Xem tại đây

Các loại trong ngôn ngữ lập trình thông thường có xu hướng hạn chế hơn, nhưng lý thuyết meta là như nhau.

Một cái gì đó tương tự như nghịch lý của Russell là một vấn đề lớn trong lý thuyết loại phụ thuộc. Đặc biệt, có

Type : Type

thường dẫn đến mâu thuẫn. Coq và công việc tương tự bằng cách lồng vũ trụ

Type_0 : Type_1

nhưng trong Coq theo mặc định những con số này là ẩn vì chúng thường không quan trọng đối với lập trình viên.

Trong một số hệ thống (Agda, Idris), quy tắc loại trong loại được bật thông qua cờ biên dịch. Nó làm cho logic không nhất quán, nhưng thường làm cho việc lập trình khám phá / chứng minh dễ dàng hơn.

Ngay cả trong các ngôn ngữ chính hơn, nghịch lý của Russell thỉnh thoảng xuất hiện. Ví dụ, trong Haskell, có thể mã hóa nghịch lý của Russell kết hợp tính ngẫu nhiên và trường hợp loại mở, cho phép người ta xây dựng các thuật ngữ khác nhau mà không cần đệ quy ngay cả ở cấp độ loại. Haskell là `` không nhất quán "(khi diễn giải như một logic theo cách thông thường) vì nó hỗ trợ đệ quy cả loại và giá trị, không đề cập đến các ngoại lệ. Không có gì, kết quả này khá thú vị.


Cảm ơn câu trả lời chi tiết của bạn - theo như bằng chứng, vẫn chưa có công cụ nào chứng minh tính đúng đắn của các chương trình trong các ngôn ngữ bắt buộc như C ++ hoặc Java, phải không? Tôi rất thích đặt tay lên một trong số này ... Tôi nhận ra đây là một tiếp tuyến hoàn chỉnh. Tôi biết về Coq và Agda, nhưng dường như chúng không phải là công cụ phù hợp để chứng minh tính đúng đắn của các chương trình được viết bằng C ++ hoặc Java.
Frank

3
có một số công cụ. Một số ít cho C, nhiều cho Java và tấn cho Ada. Xem ví dụ: Why (Java, C, Ada), Krakatoa (Java) hoặc SPARK (tập hợp con Ada với công cụ rất tốt). Đối với C ++ mặc dù, không quá nhiều. Bạn cũng có thể quan tâm đến YNot (Coq DSL).
Philip JF

3

Bạn nói đúng về động lực của Russell. Nghịch lý của ông làm vấy bẩn tất cả các lý thuyết về các tập hợp thừa nhận các tiên đề hiểu không bị hạn chế đối với hiệu ứng: bất kỳ hàm mệnh đề nào xác định một tập hợp, cụ thể là của tất cả các thực thể thỏa mãn hàm đó. Trong số các lý thuyết về hoặc dựa trên các tập hợp có lỗ hổng đó là lý thuyết tập hợp ngây thơ của Cantor và hệ thống Grundgesetze của Frege (cụ thể: tiên đề 5).

Vì các loại được coi là loại tập hợp đặc biệt, nếu không cẩn thận, một nghịch lý tương tự có thể len ​​lỏi vào một hệ thống loại. Điều đó được nói, tôi không biết bất kỳ hệ thống loại nào phải chịu số phận như vậy. Tôi chỉ có thể nhớ lại những nỗ lực ban đầu của Church trong việc xây dựng phép tính lambda trong những năm 30, hóa ra là không nhất quán (Nghịch lý Kleene-Rosser), nhưng điều đó không phải do các loại cũng không liên quan đến nghịch lý của Russell.

Cập nhật : Xem phản hồi của Philip để biết câu trả lời thực sự cho câu hỏi của bạn.


1
Cảm ơn câu trả lời của bạn. Có lẽ có những lựa chọn thay thế cho loại a-la-Russell để tránh nghịch lý Russell. Có bất kỳ giải pháp thay thế nào có bất cứ điều gì thú vị để đóng góp cho ngôn ngữ máy tính không? Các loại trần tục rất hữu ích để xác định rõ các hợp đồng giữa các phần của mã và thậm chí trước đó, để cung cấp ngữ nghĩa cho các chương trình. Sẽ có những ngữ nghĩa khác có thể có được với một cái gì đó khác hơn các loại? (Tôi KHÔNG biết đó sẽ là gì :-)
Frank

1
Có, rất nhiều lựa chọn thay thế (Quine's NF, ZFC, v.v.), nhưng tôi không thể thấy bất kỳ kết nối trực tiếp nào giữa khủng hoảng nền tảng và ngôn ngữ lập trình. Nếu bạn coi lý thuyết loại của Martin Lof là ngôn ngữ lập trình, có thể có một mối liên hệ nào đó với việc trở lại với trực giác. Liên quan đến ngữ nghĩa của các ngôn ngữ lập trình, có một số ngôn ngữ cơ bản như PDL (Logic động đề xuất) có ngữ nghĩa Kripke (hoặc thế giới có thể). Nhưng các loại dường như rất cơ bản đến nỗi chúng có thể ở phía sau hậu trường :)
Hồ Nam Rostomyan

1
Nhưng các loại là một người lập dị: bạn muốn và cần chúng, nhưng bạn muốn không phải chỉ định chúng (do đó, IMHO, tại sao chúng ta có các hệ thống suy luận bằng các ngôn ngữ như Haskell hoặc Ocaml (tôi yêu các ngôn ngữ đó)). Ở đầu kia của phổ, Python cảm thấy rất trực quan và thật dễ chịu (và hiệu quả về thời gian mã hóa) để không phải lo lắng quá nhiều về các loại trong ngôn ngữ đó. Có lẽ kiểu suy luận là tốt nhất của cả hai thế giới - nhưng đó là kỹ sư nói. Tôi chỉ mơ mộng rằng toán học có thể đóng góp một khái niệm quan trọng khác (như các loại) cho khoa học máy tính :-)
Frank

1
@Frank Mỗi lần tôi sử dụng một ngôn ngữ không có kiểu tĩnh (chủ yếu là Ruby) tôi ghét trải nghiệm này, vì tôi ghét các lỗi thời gian chạy có thể tránh được. Vì vậy, đó dường như là một vấn đề của hương vị là chủ yếu. Tôi đồng ý rằng suy luận kiểu mạnh mẽ có thể cung cấp cho bạn tốt nhất của cả hai thế giới. Đó là, có lẽ, tại sao tôi thích Scala rất nhiều.
Raphael

Tôi không tin rằng việc không có kiểu "tự động" dẫn đến lỗi thời gian chạy, vì dường như bạn ngụ ý :-) Tôi chưa bao giờ gặp vấn đề trong Python.
Frank

3

Vì bạn đề cập đến Python, câu hỏi không hoàn toàn là lý thuyết kiểu. Vì vậy, tôi cố gắng đưa ra một quan điểm rộng hơn về các loại. Các loại là những thứ khác nhau cho những người khác nhau. Tôi đã thu thập ít nhất 5 khái niệm khác nhau (nhưng có liên quan) về các loại:

  1. Loại hệ thống là hệ thống logic và thiết lập lý thuyết.

  2. Một hệ thống loại liên kết một loại với mỗi giá trị được tính toán. Bằng cách kiểm tra luồng của các giá trị này, một hệ thống loại cố gắng chứng minh hoặc đảm bảo rằng không có lỗi loại nào có thể xảy ra.

  3. Loại là một phân loại xác định một trong các loại dữ liệu khác nhau, chẳng hạn như giá trị thực, số nguyên hoặc Boolean, xác định các giá trị có thể có cho loại đó; các hoạt động có thể được thực hiện trên các giá trị của loại đó; ý nghĩa của dữ liệu; và cách các giá trị của loại đó có thể được lưu trữ

  4. Các kiểu dữ liệu trừu tượng cho phép trừu tượng hóa dữ liệu bằng các ngôn ngữ cấp cao. Các ADT thường được triển khai dưới dạng các mô-đun: giao diện của mô-đun khai báo các quy trình tương ứng với các hoạt động của ADT. Chiến lược che giấu thông tin này cho phép thay đổi mô đun mà không làm phiền các chương trình máy khách.

  5. Việc triển khai ngôn ngữ lập trình sử dụng các loại giá trị để chọn lưu trữ các giá trị cần và thuật toán cho các hoạt động trên các giá trị.

Các trích dẫn từ Wikipedia, nhưng tôi có thể cung cấp các tài liệu tham khảo tốt hơn nếu cần.

Loại 1 phát sinh từ công việc của Russel, nhưng ngày nay chúng không chỉ đơn thuần bảo vệ khỏi những nghịch lý: ngôn ngữ đánh máy của lý thuyết kiểu đồng luân là một cách mới để mã hóa toán học bằng ngôn ngữ chính thức, dễ hiểu về máy móc và là cách mới để con người hiểu được nền tảng của toán học. (Cách "cũ" là mã hóa bằng lý thuyết tập hợp tiên đề).

Các loại 2-5 phát sinh trong lập trình từ một số nhu cầu khác nhau: để tránh lỗi, phân loại các nhà thiết kế và lập trình phần mềm dữ liệu làm việc với, thiết kế các hệ thống lớn và thực hiện các ngôn ngữ lập trình một cách hiệu quả tương ứng.

Loại hệ thống trong C / C ++, Ada, Java, Python không phát sinh từ công việc của Russel hoặc mong muốn tránh lỗi. Họ nảy sinh nhu cầu mô tả các loại dữ liệu khác nhau (ví dụ: "họ là chuỗi ký tự chứ không phải số"), mô đun hóa thiết kế phần mềm và chọn cách biểu diễn mức độ thấp cho dữ liệu một cách tối ưu. Các ngôn ngữ này không có loại-1 hoặc loại-2. Java đảm bảo an toàn tương đối khỏi các lỗi không phải bằng cách chứng minh tính đúng đắn của chương trình bằng cách sử dụng hệ thống loại, mà bằng một thiết kế cẩn thận về ngôn ngữ (không có số học con trỏ) và hệ thống thời gian chạy (máy ảo, xác minh mã byte). Kiểu hệ thống trong Java không phải là một hệ thống logic hay lý thuyết tập hợp.

Tuy nhiên, hệ thống loại trong ngôn ngữ lập trình Agda là một biến thể hiện đại của hệ thống loại của Russel (dựa trên công việc sau này hoặc Per Martin-Lof và các nhà toán học khác). Hệ thống loại trong Agda được thiết kế để thể hiện các thuộc tính toán học của chương trình và bằng chứng về các tính chất đó, nó là một hệ thống logic và lý thuyết tập hợp.

Không có sự phân biệt trắng đen ở đây: nhiều ngôn ngữ phù hợp ở giữa. Ví dụ, hệ thống ngôn ngữ Haskell có nguồn gốc từ công việc của Russel, có thể được xem là hệ thống đơn giản của Agda, nhưng từ quan điểm toán học, nó không nhất quán (tự mâu thuẫn) nếu được xem là một hệ thống logic hoặc lý thuyết tập hợp.

Tuy nhiên, là một phương tiện lý thuyết để bảo vệ các chương trình Haskell khỏi các lỗi, nó hoạt động khá tốt. Bạn thậm chí có thể sử dụng các loại để mã hóa các thuộc tính nhất định và bằng chứng của chúng, nhưng không phải tất cả các thuộc tính đều có thể được mã hóa và lập trình viên vẫn có thể vi phạm các thuộc tính đã được chứng minh nếu anh ta sử dụng các bản hack bẩn được khuyến khích.

Kiểu hệ thống của Scala thậm chí còn xa hơn từ công việc của Russel và ngôn ngữ chứng minh hoàn hảo của Agda, nhưng vẫn có nguồn gốc từ công việc của Russel.

Đối với việc chứng minh tính chất của các ngôn ngữ công nghiệp có hệ thống loại không được thiết kế cho điều đó, có nhiều cách tiếp cận và hệ thống.

Đối với các phương pháp thú vị nhưng khác nhau, xem dự án nghiên cứu Coq và Microsoft Boogie. Coq dựa vào lý thuyết loại để tạo ra các chương trình bắt buộc từ các chương trình Coq. Boogie dựa vào chú thích của các chương trình mệnh lệnh với các thuộc tính và chứng minh các tính chất đó bằng phương châm định lý Z3 bằng cách sử dụng một cách tiếp cận hoàn toàn khác so với Coq.

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.