Tại sao không bị ràng buộc một lớp con của Enum trong Haskell

Có vẻ như bất kỳ trường hợp Bounded nào cũng nên thực hiện Enum. Cá nhân tôi không thể nghĩ ra một ví dụ, mặc dù nếu ai đó nghĩ ra một thứ không bệnh hoạn thì tôi sẽ hiểu tại sao không phải như vậy.

Từ việc thực hiện :itrên hai kiểu chữ, có vẻ như ngoại lệ duy nhất hiện tại trong thư viện tiêu chuẩn là dành cho các bộ dữ liệu, đó là Bounded nhưng không phải là Enums. Tuy nhiên, bất kỳ bộ giới hạn nào cũng phải là Vô số theo cách lành mạnh, chỉ bằng cách tăng phần tử cuối cùng và sau đó gói xung quanh khi nó đạt đến maxBound.

Thay đổi này có thể cũng liên quan đến việc thêm predBvà nextBhoặc một cái gì đó tương tự vào Bounded để có cách an toàn / lặp để đi qua các giá trị Enum. Trong trường hợp này toEnum 0 :: (...)sẽ bằng(toEnum 0, toEnum 0, ...) :: (...)

Một ví dụ thực tế tôi thích đến từ thế giới ngôn ngữ lập trình: tập hợp các loại trong hệ thống OO bị ràng buộc và rời rạc nhưng không thể đếm được, và được đặt hàng một phần nhưng không được sắp xếp hoàn toàn.

Thứ tự một phần trong câu hỏi là mối quan hệ phụ <:. Giới hạn trên sau đó sẽ là loại trên cùng (mà C # gọi objectvà Scala gọi Any) và giới hạn dưới sẽ là loại dưới cùng (Scala's Nothing; C # / Java không có nghĩa tương đương để nói về).

Tuy nhiên, không có cách nào để liệt kê tất cả các loại trong hệ thống loại, vì vậy bạn không thể viết một instance Enum Type. Điều này cần phải rõ ràng: người dùng có thể viết các loại của riêng họ để không có cách nào biết trước họ sẽ làm gì. Bạn có thể liệt kê tất cả các loại trong bất kỳ chương trình nào, nhưng không phải trong toàn bộ hệ thống.

Tương tự như vậy, (theo một định nghĩa hợp lý nhất định của phân nhóm,) <:là phản xạ, bắc cầu và đối xứng nhưng không phải là tổng số . Có những cặp loại không liên quan đến nhau <:. ( Catvà Doglà cả hai kiểu con của Animal, nhưng không phải là kiểu con của cái kia.)

Giả sử rằng chúng ta đang viết một trình biên dịch cho một ngôn ngữ OO đơn giản. Đây là đại diện của các loại trong hệ thống của chúng tôi:

data Type = Bottom | Class { name :: String, parent :: Type } | Top

Và định nghĩa của mối quan hệ phụ:

(<:) :: Type -> Type -> Bool
Bottom <: _ = True
Class _ _ <: Bottom = False
Class n t <: s@(Class m _)
    | n == m = True  -- you can't have different classes with the same name in this hypothetical language
    | otherwise = t <: s  -- try to find s in the parents of this class
Class _ _ <: Top = True
Top <: Top = True
Top <: _ = False

Điều này cũng cho chúng ta một mối quan hệ siêu.

(>:) :: Type -> Type -> Bool
t >: s = s <: t

Bạn cũng có thể tìm thấy giới hạn trên ít nhất của hai loại,

lub :: Type -> Type -> Type
lub Bottom s = s
lub t Bottom = t
lub t@(Class _ p) s@(Class _ q) =
    | t >: s = t
    | t <: s = s
    | p >: s = p
    | t <: q = q
    | otherwise = lub p q
lub Top _ = Top
lub _ Top = Top

Bài tập: chỉ ra rằng Typehình thành một tư thế hoàn chỉnh giới hạn theo hai cách, dưới <:và dưới >:.

Đó là bởi vì các hoạt động là độc lập, do đó, buộc chúng cùng với một mối quan hệ lớp con không thực sự mua cho bạn bất cứ thứ gì. Giả sử bạn muốn tạo một loại tùy chỉnh đã triển khai Bounded, có thể Doublesbị ràng buộc giữa tối đa và tối thiểu, nhưng bạn không cần bất kỳ Enumthao tác nào. Nếu Boundedlà một lớp con, dù sao bạn cũng sẽ phải thực hiện tất cả các Enumhàm, chỉ để biên dịch nó.

Sẽ không có vấn đề gì nếu việc triển khai hợp lý cho Enumbất kỳ số lượng máy chữ nào khác. Nếu bạn không thực sự cần nó, bạn không nên bị buộc phải thực hiện nó.

Tương phản điều này với nói, Ordvà Eq. Ở đó, các Ordhoạt động phụ thuộc vào các hoạt động Eq, vì vậy sẽ hợp lý khi yêu cầu lớp con để tránh trùng lặp và đảm bảo tính nhất quán.