Solidny haskell bez błędów

Question

Aktualnie uczę się Haskella. Jedną z motywacji, dla których wybrałem ten język, było napisanie oprogramowania o bardzo wysokim stopniu odporności, tj. Funkcji, które są w pełni zdefiniowane, matematycznie deterministyczne i nigdy nie powodują awarii ani nie powodują błędów. Nie chodzi mi o awarię spowodowaną przez predykaty systemu ("system z pamięci", "komputer w ogniu" itp.), Nie są one interesujące i mogą po prostu załamać cały proces. Nie mam również na myśli błędnego zachowania spowodowanego przez nieważne deklaracje (pi = 4).

Zamiast tego odnoszę się do błędów spowodowanych przez błędne stany, które chcę usunąć, czyniąc te stany niereprezentowalnymi i nie nadającymi się do skompilowania (w niektórych funkcjach) poprzez ścisłe pisanie statyczne. W moim umyśle nazwałem te funkcje "czystymi" i uznałem, że silny system typów pozwoli mi to osiągnąć. Jednak Haskell nie definiuje "czystego" w ten sposób i pozwala programom na awarię przez error w dowolnym kontekście.

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

Jest to całkowicie dopuszczalne i nie jest dziwne w ogóle. Niezadowalające jest jednak to, że Haskell nie wydaje się oferować pewnej funkcjonalności, aby zabronić definicji funkcji, które mogłyby prowadzić do oddziałów przy użyciu error.

Oto zmyślony przykład dlaczego uważam to rozczarowujące:

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 

Powiedzmy, że jestem paranoikiem, że czysta funkcje readFruit i printFruit naprawdę nie powiedzie się z powodu stanów niedotykane. Można sobie wyobrazić, że kodeks ma na celu wystrzelenie rakiety pełnej astronautów, która w absolutnie krytycznej rutynie potrzebuje serializacji i odseparowania wartości owoców.

Pierwszym niebezpieczeństwem jest naturalne, że popełniliśmy błąd w dopasowywaniu wzorców, ponieważ daje to nam przerażające błędne stany, których nie można obsłużyć. Na szczęście Haskell dostarcza zbudowany w taki sposób, aby zapobiec tych, po prostu skompilować nasz program z -Wall który obejmuje -fwarn-incomplete-patterns i AHA:

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

Zapomnieliśmy serializacji brzoskwini i showFruit byłby wyrzucony błąd. To się łatwo naprawić, po prostu dodajemy:

showFruit Peach = "A peach" 

Program kompiluje się bez ostrzeżenia, niebezpieczeństwo zażegnane! Uruchamiamy rakietę ale nagle program wywala się z:

Maybe.fromJust: Nothing 

Rakieta jest skazany i uderza ocean spowodowane następującymi wadliwego line:

printFruit x = showFruit $ fromJust x 

Zasadniczo fromJust ma oddział, gdzie podnosi Error więc nie chcieliśmy, aby program się kompilował, jeśli spróbujemy go użyć od printFruit absolutnie musi być "super" czysty. Mogliśmy ustalona, ​​że ​​na przykład poprzez zastąpienie linii z:

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

Uważam to za dziwne, że Haskell zdecyduje się wprowadzić ścisłe wpisywanie i niekompletny wykrywanie wzorców, wszystko w pogoni nobel zapobiegania nieprawidłowe stany od przedstawianego ale upadki tuż przed linią mety, nie dając programistom sposobu na wykrycie gałęzi na error, gdy nie są dozwolone.W pewnym sensie sprawia to, że Haskell jest mniej odporny niż Java, która zmusza Cię do zadeklarowania wyjątków, które twoje funkcje mogą podnieść.

Najbardziej banalnym sposobem wdrożenia tego byłoby po prostu nieokreślone error w jakiś sposób, lokalnie dla funkcji i dowolnej funkcji używanej przez jej równanie przez jakąś formę powiązanej deklaracji. Jednak nie wydaje się to możliwe.

The wiki page about errors vs exceptions wymienia w tym celu rozszerzenie o nazwie "Extended Static Checking", ale prowadzi to po prostu do zerwania łącza.

W zasadzie sprowadza się do: Jak uzyskać powyższy program, aby nie skompilować, ponieważ używa on fromJust? Wszystkie pomysły, sugestie i rozwiązania są mile widziane.

Answer 1

Odpowiedź była taka, że ​​chciałem mieć poziom sprawdzania całości, którego Haskell niestety nie zapewnia (jeszcze?).

Alternatywnie chcę mieć typy zależne (na przykład Idris) lub statyczny weryfikator (np. Liquid Haskell) lub wykrywanie lint składni (np. hlint).

Naprawdę zajmuję się teraz Idrisem, wydaje się niesamowitym językiem. Oto talk by the founder of Idris, które mogę polecić oglądać.

Kredyty za te odpowiedzi otrzymują: @duplode, @chi, @ user3237465 i @luqui.

Answer 2

Twoja główna skarga dotyczy numeru fromJust, ale biorąc pod uwagę, że jest to zasadniczo sprzeczne z Twoimi celami, dlaczego go używasz?

Pamiętaj, że najważniejszym powodem dla error jest to, że nie wszystko można zdefiniować w sposób gwarantujący system typów, więc posiadanie "To nie może się zdarzyć, zaufaj mi" ma sens. fromJust pochodzi z tego sposobu myślenia "czasami wiem lepiej niż kompilator". Jeśli nie zgadzasz się z tym nastawieniem, nie używaj go. Ewentualnie nie nadużywaj tego tak, jak robi to przykład.

EDIT:

Aby rozwinąć na moim punkcie, myśleć o tym, jak można zaimplementować co prosicie (ostrzeżenia dotyczące korzystania z funkcji częściowe). Gdzie pojawi się ostrzeżenie w poniższym kodzie?

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

Wszystkie te elementy nie są statyczne. (Przepraszam, jeśli składnia następny jest wyłączony, jest późno)

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 tutaj jest znowu bezpieczne, ale j nie jest. Która metoda powinna zwrócić ostrzeżenie? Co robimy, gdy niektóre lub wszystkie z tych metod są zdefiniowane poza naszą funkcją. Co robisz w przypadku k, gdzie jest warunkowo częściowy? Czy niektóre lub wszystkie te funkcje zawiodą?

Wykonując połączenie, kompilator łączy wiele skomplikowanych problemów. Zwłaszcza jeśli weźmiesz pod uwagę, że ostrożny wybór bibliotek go unika.

W obu przypadkach rozwiązaniem IMO dla tego rodzaju problemów jest użycie narzędzia po lub w trakcie kompilacji w celu poszukiwania problemów, zamiast modyfikowania kompilatora. Takie narzędzie może łatwiej zrozumieć "twój kod" w porównaniu do "jego kodu" i lepiej określić, gdzie najlepiej ostrzec w przypadku niewłaściwego użycia. Można również dostroić go bez konieczności dodawania wiązki adnotacji do pliku źródłowego, aby uniknąć fałszywych alarmów. Nie znam jakiegoś narzędzia z offhandu, a proponuję jedno.

Answer 3

Haskell pozwala na dowolną rekurencję ogólną, więc nie jest tak, że wszystkie programy Haskell byłyby z konieczności całkowite, gdyby tylko error w różnych formach zostały usunięte. Oznacza to, że możesz zdefiniować error a = error a, aby zająć się każdym przypadkiem, którego nie chcesz obsługiwać. Błąd runtime jest po prostu bardziej przydatny niż nieskończona pętla.

Nie należy myśleć o error jako podobnej do wyjątku Java w ogrodzie. error to błąd asercji reprezentujący błąd programowania, a funkcja taka jak fromJust, która może wywoływać error jest asercją.Nie powinieneś próbować wychwycić wyjątku wyprodukowanego przez error, z wyjątkiem specjalnych przypadków, takich jak serwer, który musi nadal działać, nawet jeśli program obsługi żąda zgłoszenia błędu programistycznego.