Faulheit/Strenge zwischen Daten und newtype

Question

Ich habe zu kämpfen, um zu verstehen, warum diese zwei Schnipsel unterschiedliche Ergebnisse unter der sogenannten "Strenge Analyse des armen Mannes" produzieren.

Das erste Beispiel verwendet data (eine korrekte Instanz Applicative vorausgesetzt):

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

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

Die zweite verwendet newtype. Es gibt keinen anderen Unterschied:

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

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

literal x einen Parser ist das ein Zeichen des Eingangs gelingt es raubend, wenn sein Argument mit dem ersten Token übereinstimmt. In diesem Beispiel schlägt es fehl, da ; nicht mit a übereinstimmt. Das data Beispiel sieht jedoch immer noch, dass der nächste Parser nicht definiert ist, während das newtype Beispiel nicht funktioniert.

Ich habe gelesen this, this und this, aber verstehe sie nicht gut genug, um zu bekommen, warum das erste Beispiel nicht definiert ist. Es scheint mir, dass in diesem Beispiel newtype ist mehr faul als data, das Gegenteil von dem, was die Antworten sagten. (Mindestens one other person wurde auch dadurch verwirrt).

Warum ändert sich die Definition dieses Beispiels von data zu newtype?

---

Hier ist eine andere Sache, die ich entdeckt: mit diesem Applicative Beispiel die data Parser über Ausgänge undefined:

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)) 

während bei diesem Fall der data Parser oben tut nicht Ausgang undefiniert (unter der Annahme, eine korrekte Monad-Instanz für Parser s):

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

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

---

Voll Code-Schnipsel:

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

Wie Sie wahrscheinlich wissen, ist der Hauptunterschied zwischen data und newtype dass mit data ist, dass data Konstrukteuren faul sind, während newtype streng, dh die folgenden Arten gegeben

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

dann D ⊥ `seq` x = x, aber N ⊥ `seq` x = ⊥.

Was weniger ist vielleicht allgemein bekannt ist jedoch, dass, wenn Sie Mustererkennung auf diesen Konstrukteuren, die Rollen sind „umgekehrt“, das heißt mit

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

dann constD x ⊥ = ⊥, aber constN x ⊥ = x.

Dies ist, was in Ihrem Beispiel passiert.

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

Mit data wird die Mustererkennung in der Definition von <*> auseinander gehen sofort, wenn entweder der Argumente ⊥ sind, aber mit newtype die Konstrukteure werden ignoriert und es ist , als ob Sie geschrieben hatte

f <*> x = h where 

, die nur für x = ⊥ abweichen, wenn x angefordert wird.

Answer 2

Der Unterschied zwischen data und newtype ist, dass data ist "aufgehoben" und newtype ist nicht. Das bedeutet, dass die data eine zusätzliche ⊥ hat - in diesem Fall bedeutet dies, dass undefined/= Parser undefined. Wenn Ihr Codemuster auf Parser x übereinstimmt, erzwingt es einen Wert ⊥ wenn der Konstruktor.

Wenn Sie einen data Konstruktor mit einem Muster vergleichen, wird dieser ausgewertet und zerlegt, um sicherzustellen, dass es nicht ⊥ ist. Zum Beispiel:

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

So Mustervergleich auf ein data Konstruktor ist streng, und es zwingen wird. Eine newtype wird dagegen genau so dargestellt, wie der Typ, den ihr Konstruktor umschließt. So passend auf ein newtype Konstruktor absolut nichts:

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

Es gibt wahrscheinlich zwei Möglichkeiten data Programm so zu ändern, dass es nicht zum Absturz bringen. Eine wäre die Verwendung einer unwiderlegbaren Musterübereinstimmung in Ihrer Instanz, die immer "erfolgreich" sein wird (aber die Verwendung der angepassten Werte irgendwo später könnte fehlschlagen). Jede newtype Übereinstimmung verhält sich wie ein unwiderlegbares Muster (da es keinen Konstruktor gibt, auf den strikt zu achten ist).

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

Die andere wäre Parser undefined von undefined stattdessen zu verwenden:

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

Dieses Spiel wird erfolgreich sein, weil es ein gültiger Foo Wert ist, der auf abgestimmt ist wird. Es enthält undefined, aber das ist nicht relevant, da wir es nicht verwenden - wir betrachten nur den obersten Konstruktor.

---

Zusätzlich zu allen Links, die Sie gaben, könnten Sie this article relevant finden.