Mạnh mẽ haskell mà không có lỗi

Question

Tôi hiện đang học Haskell. Một trong những động lực tại sao tôi chọn ngôn ngữ này là viết phần mềm với mức độ mạnh mẽ rất cao, tức là các hàm được xác định đầy đủ, xác định toán học và không bao giờ bị lỗi hoặc tạo ra lỗi. Tôi không có nghĩa là thất bại gây ra bởi các vị từ của hệ thống ("hệ thống ra khỏi bộ nhớ", "máy tính trên lửa" vv), những người không phải là thú vị và có thể chỉ đơn giản là sụp đổ toàn bộ quá trình. Tôi cũng không có nghĩa là hành vi sai trái do khai báo không hợp lệ (pi = 4). Thay vào đó tôi tham khảo các lỗi gây ra bởi các trạng thái sai lầm mà tôi muốn loại bỏ bằng cách làm cho các trạng thái đó không thể đại diện và không thể compilable (trong một số hàm) thông qua gõ tĩnh nghiêm ngặt. Trong tâm trí của tôi, tôi gọi những hàm này là "thuần khiết" và nhận ra rằng hệ thống kiểu mạnh mẽ sẽ cho phép tôi thực hiện điều này. Tuy nhiên, Haskell không định nghĩa "thuần túy" theo cách này và cho phép các chương trình gặp sự cố thông qua error trong mọi ngữ cảnh.

Why is catching an exception non-pure, but throwing an exception is pure?

Điều này hoàn toàn có thể chấp nhận được và không lạ chút nào. Điều đáng thất vọng tuy nhiên là Haskell không xuất hiện để cung cấp một số chức năng để cấm định nghĩa chức năng có thể dẫn đến các chi nhánh bằng cách sử dụng error.

Dưới đây là một ví dụ contrived tại sao tôi tìm thấy điều này đáng thất vọng:

module Main where 
import Data.Maybe 

data Fruit = Apple | Banana | Orange Int | Peach 
    deriving(Show) 

readFruit :: String -> Maybe Fruit 
readFruit x = 
    case x of 
     "apple" -> Just Apple 
     "banana" -> Just Banana 
     "orange" -> Just (Orange 4) 
     "peach" -> Just Peach 
     _ -> Nothing 

showFruit :: Fruit -> String 
showFruit Apple = "An apple" 
showFruit Banana = "A Banana" 
showFruit (Orange x) = show x ++ " oranges" 

printFruit :: Maybe Fruit -> String 
printFruit x = showFruit $ fromJust x 

main :: IO() 
main = do 
    line <- getLine 
    let fruit = readFruit line 
    putStrLn $ printFruit fruit 
    main 

Hãy nói rằng tôi hoang tưởng rằng các chức năng tinh khiết readFruit và printFruit thực sự không thất bại do tiểu bang unhanded. Bạn có thể tưởng tượng rằng mã là để tung ra một tên lửa đầy đủ các phi hành gia mà trong một thói quen hoàn toàn quan trọng cần phải tuần tự hóa và unserialize các giá trị trái cây.

Nguy hiểm đầu tiên là tự nhiên mà chúng tôi đã phạm sai lầm trong kết hợp mẫu của chúng tôi vì điều này cho chúng ta những trạng thái sai lầm đáng sợ không thể xử lý được. Rất may Haskell cung cấp được xây dựng theo những cách để ngăn chặn những người, chúng tôi chỉ đơn giản là biên dịch chương trình của chúng tôi với -Wall trong đó bao gồm -fwarn-incomplete-patterns và AHA:

src/Main.hs:17:1: Warning: 
    Pattern match(es) are non-exhaustive 
    In an equation for ‘showFruit’: Patterns not matched: Peach 

Chúng tôi quên serialize trái cây Peach và showFruit sẽ ném một lỗi. Đó là một sửa chữa dễ dàng, chúng tôi chỉ cần thêm:

showFruit Peach = "A peach" 

Chương trình hiện đang biên dịch mà không có cảnh báo, nguy hiểm bị đảo ngược! Chúng tôi khởi động tên lửa nhưng đột nhiên chương trình bị treo với:

Maybe.fromJust: Nothing 

Các tên lửa được cam chịu và truy cập các đại dương gây ra bởi dòng bị lỗi sau:

printFruit x = showFruit $ fromJust x 

Về cơ bản fromJust có một chi nhánh nơi mà nó đặt ra một Error vì vậy chúng tôi thậm chí không muốn chương trình biên dịch nếu chúng tôi cố gắng sử dụng nó từ printFruit hoàn toàn phải là "siêu" thuần túy. Chúng ta có thể cố định ví dụ bằng cách thay thế phù hợp với:

printFruit x = maybe "Unknown fruit!" (\y -> showFruit y) x 

tôi thấy nó lạ mà Haskell quyết định để thực hiện gõ nghiêm ngặt và đầy đủ phát hiện mô hình, tất cả trong việc theo đuổi nobel ngăn ngừa trạng thái không hợp lệ từ việc biểu diễn nhưng thác chỉ ở phía trước của dòng kết thúc bằng cách không cho các lập trình viên một cách để phát hiện các chi nhánh đến error khi chúng không được phép.Theo một nghĩa nào đó, điều này làm cho Haskell kém mạnh mẽ hơn khi Java buộc bạn phải khai báo các ngoại lệ mà các chức năng của bạn được phép nâng lên.

Cách nhỏ nhất để thực hiện điều này sẽ đơn giản là không xác định error theo cách nào đó, cục bộ cho hàm và hàm bất kỳ được sử dụng bởi phương trình của nó. Tuy nhiên điều này dường như không thể.

The wiki page about errors vs exceptions đề cập đến một tiện ích mở rộng được gọi là "Kiểm tra tĩnh mở rộng" cho mục đích này thông qua hợp đồng nhưng nó chỉ dẫn đến một liên kết bị hỏng.

Về cơ bản, nó tóm tắt: Làm cách nào để chương trình ở trên không biên dịch được vì nó sử dụng fromJust? Tất cả các ý tưởng, đề xuất và giải pháp đều được chào đón.

Answer 1

Câu trả lời là tôi muốn là một mức độ toàn bộ kiểm tra mà Haskell không may không cung cấp (chưa?).

Hoặc tôi muốn các loại phụ thuộc (ví dụ: Idris) hoặc trình xác minh tĩnh (ví dụ: Liquid Haskell) hoặc phát hiện lint cú pháp (ví dụ: hlint).

Tôi thực sự đang tìm kiếm Idris bây giờ, có vẻ như đó là một ngôn ngữ tuyệt vời. Đây là số talk by the founder of Idris mà tôi có thể khuyên bạn nên xem.

Tín dụng cho những câu trả lời này sẽ chuyển đến @duplode, @chi, @ user3237465 và @luqui.

Answer 2

Khiếu nại chính của bạn là về fromJust, nhưng về cơ bản nó chống lại mục tiêu của bạn là gì, tại sao bạn sử dụng nó?

Hãy nhớ rằng lý do lớn nhất cho error là không phải mọi thứ đều có thể được xác định theo cách mà hệ thống kiểu có thể đảm bảo, vì vậy việc có "Điều này không thể xảy ra, tin tưởng tôi" có ý nghĩa. fromJust xuất phát từ suy nghĩ này của "đôi khi tôi biết rõ hơn trình biên dịch". Nếu bạn không đồng ý với suy nghĩ đó thì không sử dụng nó. Ngoài ra, đừng lạm dụng nó như ví dụ này.

EDIT:

Mở rộng trên quan điểm của tôi, suy nghĩ về cách bạn sẽ thực hiện những gì bạn đang yêu cầu (cảnh báo về việc sử dụng các chức năng một phần). Cảnh báo sẽ áp dụng ở đâu trong đoạn mã sau?

a = fromJust $ Just 1 
b = Just 2 
c = fromJust $ c 
d = fromJust 
e = d $ Just 3 
f = d b 

Tất cả những điều này là tĩnh không phải là một phần sau khi tất cả. (Xin lỗi nếu cú ​​pháp tiếp theo của này là tắt, nó là muộn)

g x = fromJust x + 1 
h x = g x + 1 
i = h $ Just 3 
j = h $ Nothing 
k x y = if x > 0 then fromJust y else x 
l = k 1 $ Just 2 
m = k (-1) $ Just 3 
n = k (-1) $ Nothing 

i đây là một lần nữa an toàn, nhưng không phải là j. Phương thức nào sẽ trả lại cảnh báo? Chúng ta làm gì khi một số hoặc tất cả các phương thức này được định nghĩa bên ngoài chức năng của chúng ta. Bạn làm gì trong trường hợp của k nơi nó có điều kiện một phần? Một số hoặc tất cả các chức năng này có bị lỗi không?

Bằng cách làm cho trình biên dịch thực hiện cuộc gọi này, bạn đang làm xáo trộn rất nhiều vấn đề phức tạp. Đặc biệt là khi bạn xem xét lựa chọn thư viện cẩn thận tránh nó.

Trong cả hai trường hợp, giải pháp IMO đối với các loại vấn đề này là sử dụng một công cụ sau hoặc trong quá trình biên dịch để tìm kiếm các vấn đề thay vì sửa đổi trình biên dịch. Một công cụ như vậy có thể dễ dàng hiểu "mã của bạn" so với "mã của chúng" và xác định tốt hơn nơi tốt nhất để cảnh báo bạn khi sử dụng không phù hợp. Bạn cũng có thể điều chỉnh nó mà không cần phải thêm một loạt chú thích vào tệp nguồn của mình để tránh các kết quả dương tính giả. Tôi không biết một công cụ nào hoặc tôi sẽ đề nghị một công cụ.

Answer 3

Haskell cho phép đệ quy chung tùy ý, vì vậy nó không phải là tất cả các chương trình Haskell nhất thiết phải là tổng số, nếu chỉ có error trong các hình thức khác nhau của nó đã bị xóa. Tức là, bạn chỉ có thể xác định error a = error a để xử lý mọi trường hợp bạn không muốn xử lý anyways. Lỗi thời gian chạy chỉ hữu ích hơn vòng lặp vô hạn.

Bạn không nên nghĩ đến error tương tự như ngoại lệ Java nhiều loại vườn. error là lỗi xác nhận đại diện cho lỗi lập trình và chức năng như fromJust có thể gọi error là xác nhận.Bạn không nên cố gắng nắm bắt ngoại lệ được tạo ra bởi error ngoại trừ trong trường hợp đặc biệt như máy chủ phải tiếp tục chạy ngay cả khi trình xử lý yêu cầu gặp phải lỗi lập trình.