Lenistwo/surowość między danymi a nowym typem

Question

Staram się zrozumieć, dlaczego te dwa fragmenty dają różne wyniki w ramach tak zwanej "analizy ścisłości człowieka ubogiego".

Pierwszy przykład wykorzystuje data (zakładając właściwe wystąpienie aplikacyjny)

data Parser t a = Parser { 
     getParser :: [t] -> Maybe ([t], a) 
    } 

> getParser (pure (,) <*> literal ';' <*> undefined) "abc" 
*** Exception: Prelude.undefined 

Drugi wykorzystuje newtype. Nie ma innej różnicy:

newtype Parser t a = Parser { 
     getParser :: [t] -> Maybe ([t], a) 
    } 

> getParser (pure (,) <*> literal ';' <*> undefined) "abc" 
Nothing 

literal x jest parser że powiedzie zużywa jeden znak wejścia, jeśli jego argumentem mecze pierwszego tokena. W tym przykładzie kończy się niepowodzeniem, ponieważ ; nie pasuje do a. Jednak w przykładzie data nadal widać, że następny parser jest niezdefiniowany, podczas gdy przykład newtype nie.

Przeczytałem this, this i this, ale nie rozumiem ich wystarczająco dobrze, aby dowiedzieć się, dlaczego pierwszy przykład jest niezdefiniowany. Wydaje mi się, że w tym przykładzie newtype jest leniwy niż data, przeciwieństwo tego, co mówią odpowiedzi. (Przynajmniej przez to też zdezorientowało to one other person).

Dlaczego zmiana z data na newtype zmienia definicję tego przykładu?

---

Oto kolejna rzecz odkryłem: z tym aplikacyjnych przykład data parser powyżej wyjść niezdefiniowany:

instance Applicative (Parser s) where 
    Parser f <*> Parser x = Parser h 
    where 
     h xs = 
     f xs >>= \(ys, f') -> 
     x ys >>= \(zs, x') -> 
     Just (zs, f' x') 

    pure a = Parser (\xs -> Just (xs, a)) 

natomiast w tym przypadku data parser powyżej robi nie wyjście niezdefiniowany (zakładając, poprawna instancja Monada dla Parser s):

instance Applicative (Parser s) where 
    f <*> x = 
     f >>= \f' -> 
     x >>= \x' -> 
     pure (f' x') 

    pure = pure a = Parser (\xs -> Just (xs, a)) 

---

Pełna fragment kodu:

import Control.Applicative 
import Control.Monad (liftM) 

data Parser t a = Parser { 
     getParser :: [t] -> Maybe ([t], a) 
    } 


instance Functor (Parser s) where 
    fmap = liftM 

instance Applicative (Parser s) where 
    Parser f <*> Parser x = Parser h 
    where 
     h xs = f xs >>= \(ys, f') -> 
     x ys >>= \(zs, x') -> 
     Just (zs, f' x') 

    pure = return 


instance Monad (Parser s) where 
    Parser m >>= f = Parser h 
    where 
     h xs = 
      m xs >>= \(ys,y) -> 
      getParser (f y) ys 

    return a = Parser (\xs -> Just (xs, a)) 


literal :: Eq t => t -> Parser t t 
literal x = Parser f 
    where 
    f (y:ys) 
     | x == y = Just (ys, x) 
     | otherwise = Nothing 
    f [] = Nothing 

Answer 1

Jak zapewne wiecie, główną różnicą między data i newtype jest to, że z data że data konstruktorzy są leniwi podczas newtype jest ścisły, czyli biorąc pod uwagę następujące rodzaje

data D a = D a 
newtype N a = N a 

następnie D ⊥ `seq` x = x, ale N ⊥ `seq` x = ⊥.

Co jest może mniej znany jest jednak to, że podczas spotkania na wzór tych konstruktorów, role są „odwrócone”, to znaczy z

constD x (D y) = x 
constN x (N y) = x 

następnie constD x ⊥ = ⊥, ale constN x ⊥ = x.

Oto, co dzieje się w twoim przykładzie.

Parser f <*> Parser x = Parser h where ... 

Z data, mecz wzór w definicji <*> będzie odbiegać od razu, czy też argumenty są ⊥, ale newtype konstruktorzy są ignorowane i jest jak gdybyś napisał

f <*> x = h where 

, które będą rozbieżne tylko dla x = ⊥, jeśli wymagane jest x.

Answer 2

Różnica data i newtype jest data jest „podnoszone” i newtype nie. Oznacza to, że data ma dodatkowe ⊥ - w tym przypadku oznacza to, że undefined/= Parser undefined. Kiedy twój wzór Applicative - pasuje do Parser x, wymusza wartość ⊥, jeśli konstruktor.

Po dopasowaniu do wzoru na konstruktorze data, jest on oceniany i rozbierany, aby upewnić się, że nie jest ⊥. Na przykład:

λ> data Foo = Foo Int deriving Show 
λ> case undefined of Foo _ -> True 
*** Exception: Prelude.undefined 

Więc dopasowywania wzorca na data konstruktora jest surowe, i będzie go zmuszać. Z drugiej strony, newtype jest reprezentowany w dokładnie taki sam sposób, jak typ, który owija jego konstruktor. Tak dopasowane na newtype konstruktora robi absolutnie nic:

λ> newtype Foo = Foo Int deriving Show 
λ> case undefined of Foo _ -> True 
True 

Istnieją prawdopodobnie dwa sposoby, aby zmienić swój program data taki sposób, że nie psuje. Jedną z nich jest użycie niezaprzeczalnego dopasowania wzorców w instancji Applicative, która zawsze "powiedzie się" (ale użycie dopasowanych wartości w dowolnym miejscu później może się nie udać). Każdy mecz newtype zachowuje się jak niezaprzeczalny wzorzec (ponieważ nie ma konstruktora, który mógłby dopasować, zgodnie ze ścisłością).

λ> data Foo = Foo Int deriving Show 
λ> case undefined of ~(Foo _) -> True 
True 

Drugi byłoby użyć Parser undefined zamiast undefined:

λ> case Foo undefined of Foo _ -> True 
True 

Ten mecz uda, bo nie jest prawidłową wartość Foo że to jest dopasowana na. Zdarza się, że zawiera undefined, ale to nie ma znaczenia, ponieważ nie używamy go - patrzymy tylko na najwyższy konstruktor.

---

Oprócz wszystkich linków, które podałeś, możesz znaleźć odpowiednie this article.