Các vấn đề thực tế với các loại giao lộ và công đoàn là gì?

Tôi đang thiết kế một ngôn ngữ lập trình hàm đơn giản gõ như một kinh nghiệm học tập.

Dường như hệ thống loại tôi đã triển khai cho đến nay có thể (với một chút công việc phụ) kết hợp các loại giao cắt và kết hợp, ví dụ: bạn có thể có:

• <Union String Integer>
• <Union Integer Foo>
• Giao điểm của hai loại trên sẽ là một đồng bằng Integer
• Sự kết hợp của hai loại sẽ là <Union String Integer Foo>

Tất nhiên, điều này là có thể, không cần thiết có nghĩa là nó là một ý tưởng thiết kế tốt. Cụ thể, tôi hơi lo ngại về những khó khăn khi thực hiện khi giữ các loại rời rạc và / hoặc xử lý chồng chéo.

Những ưu / nhược điểm của việc kết hợp các tính năng như vậy trong hệ thống loại là gì?

Dưới đây là một số điều cần ghi nhớ:

• Mặc dù chúng ta thường nghĩ rằng chúng ta biết ý nghĩa của chúng ta đối với giao lộ và liên kết theo lý thuyết tập hợp, đã có một số cách khác nhau về chính xác các loại giao cắt và kết hợp là gì . Vì vậy, đáng để ghim nó xuống trước khi bạn bắt tay vào thực hiện.
• $S \sqsubset A$"là" tinh chỉnh ") trong khi quy tắc hình thành cho các sản phẩm và khoản tiền thông thường là $S$$A$ $$\frac{S\sqsubset A \quad T \sqsubset A}{S\cap T\sqsubset A}\qquad \frac{S\sqsubset A \quad T \sqsubset A}{S\cup T\sqsubset A}$$ $$\frac{S\sqsubset A \quad T \sqsubset B}{S* T\sqsubset A*B}\qquad \frac{S\sqsubset A \quad T \sqsubset B}{S+T\sqsubset A+B}$$
• Vì các giao lộ và công đoàn có thể được sử dụng để đưa ra các xác nhận chính xác hơn về hành vi thời gian chạy của chương trình, nên việc gõ trở nên nhạy cảm với thứ tự đánh giá là điều đương nhiên. Ví dụ, các bài báo (2) và (4) dưới đây đã giải thích lý do tại sao các quy tắc gõ và phân loại "rõ ràng" (và khá chuẩn) cho các giao lộ và công đoàn thực sự không có căn cứ đối với các ngôn ngữ giống ML (do sự hiện diện của các tác dụng phụ và không- chấm dứt). Bạn đa được cảnh bao!
• Vì những lý do tương tự, suy luận kiểu toàn cầu thường trở nên không thực tế hoặc không thể giải quyết được. Thật vậy, toàn bộ khái niệm "loại chính" được cho là cá trích đỏ, vì một hàm có thể đáp ứng nhiều tính chất khác nhau không liên quan đến mục đích sử dụng của nó (ví dụ: " foo lấy số nguyên tố cho số nguyên lớn hơn 7"). Thay vào đó, các cách tiếp cận thực tế đối với các giao lộ và công đoàn (xem (3) , (4) ) thường dựa trên sự kết hợp giữa suy luận và kiểm tra.

Tôi cho rằng một số điểm trên nghe có vẻ tiêu cực, mặc dù tôi sẽ không gọi chúng là "khuyết điểm" mà chỉ là "thực tế" của các loại giao lộ và liên minh. Mặt khác, từ góc độ thiết kế ngôn ngữ, một lý do để nỗ lực hỗ trợ các giao lộ và hiệp hội (và để làm cho đúng!) Là chúng cho phép các thuộc tính chính xác hơn của các chương trình được thể hiện theo cách khá gia tăng, đòi hỏi một chuyển đổi mạnh mẽ hơn nhiều so với, nói, lý thuyết loại phụ thuộc.

Một danh sách đọc ngắn gọn:

1. Thiết kế ngôn ngữ lập trình Forsythe của John C. Reynold
2. Các loại giao nhau và hiệu ứng tính toán của Rowan Davies và Frank Pfenning
3. Kiểm tra loại sàng lọc thực tế của Rowan Davies (luận văn)
4. Đánh máy ba chiều của Joshua Dunfield và Frank Pfenning