<html><body>The thing is, that one ALWAYS wants to create a union of types, and not merely an ad-hock list of data declarations. So why does it take more code to do "the right thing(tm)" than to do "the wrong thing(r)"? Lets take an example from Conor McBride's "she" https://github.com/timthelion/her-lexer/blob/master/src/Language/Haskell/Her/HaLay.lhs#L139 Line 139 we have a case statement:<br><br>> ((i, t) : its') -> case (m, t) of<br>> (Lay _ j, _) | not (null acc) && i <= j -> (reverse acc, its)<br>> (Lay _ _, Semi) -> (reverse acc, its)<br>> (Lay k _, KW e) | elem (k, e) layDKillaz -> (reverse acc, its)<br>> (Lay _ _, Clo _) -> (reverse acc, its)<br>> (Bra b, Clo b') | b == b' -> (reverse acss, its')<br>> (m, Ope b) -> case getChunks (Bra b) [] its' of<br>> (cs, its) -> getChunks m (B b cs : acss) its<br>> (m, KW e) | elem e lakeys -> case getLines (Seek m e) [] its' of<br>> (css, its) -> getChunks m ((L e css) : acss) its<br>> _ -> getChunks m (t : acss) its'<br><br>Maybe we would want to re-factor this like so:<br><br>> ((i, t) : its') -> case (m, t) of<br>> layTup@(Lay{}, _) | layTest layTup -> (reverse acc, its)<br>> (Bra b, Clo b') | b == b' -> (reverse acss, its')<br>> (m, Ope b) -> case getChunks (Bra b) [] its' of<br>> (cs, its) -> getChunks m (B b cs : acss) its<br>> (m, KW e) | elem e lakeys -> case getLines (Seek m e) [] its' of<br>> (css, its) -> getChunks m ((L e css) : acss) its<br>> _ -> getChunks m (t : acss) its'<br><br>> where<br>> layTest :: (ChunkMode,Tok) -> Bool<br>> layTest (Lay _ j, _) | not (null acc) && i <= j = True<br>> layTest (Lay _ _, Semi) = True<br>> layTest (Lay k _, KW e) | elem (k, e) layDKillaz = True<br>> layTest (Lay _ _, Clo _) = True<br>> layTest _ = False<br><br>You see what's wrong with layTest's type? It shouldn't be taking a (ChunkMode,Tok) but rather a (Lay,Tok). You ALWAYS run into this. Perhaps you would understand the problem better, if I hadn't said that the data union of types is too ugly, but that the normal data is too pretty? Everyone ends up getting caught in this trap. And the only way out is to re-write your code with better typing.<br><br>Timothy<br><br><p>Od: Tim Docker <tim@dockerz.net><br>Datum: 2. 9. 2012<br>Předmět: Re: [Haskell-cafe] Over general types are too easy to make.</p>---------- Původní zpráva ----------<br><blockquote>On 01/09/12 04:00, timothyhobbs@seznam.cz wrote:<br>> I'd have to say that there is one(and only one) issue in Haskell that <br>> bugs me to the point where I start to think it's a design flaw:<br>><br>> It's much easier to type things over generally than it is to type <br>> things correctly.<br>><br>> Say we have a<br>><br>> >data BadFoo =<br>> > BadBar{<br>> > badFoo::Int} |<br>> > BadFrog{<br>> > badFrog::String,<br>> > badChicken::Int}<br>><br>> This is fine, until we want to write a function that acts on Frogs but <br>> not on Bars. The best we can do is throw a runtime error when passed <br>> a Bar and not a Foo:<br>><br>> >deBadFrog :: BadFoo -> String<br>> >deBadFrog (BadFrog s _) = s<br>> >deBadFrog BadBar{} = error "Error: This is not a frog."<br>><br>> We cannot type our function such that it only takes Frogs and not <br>> Bars. This makes what should be a trivial compile time error into a <br>> nasty runtime one :(<br>><br>> The only solution I have found to this is a rather ugly one:<br>><br>> >data Foo = Bar BarT | Frog FrogT<br>><br>> If I then create new types for each data constructor.<br>><br>> >data FrogT = FrogT{<br>> > frog::String,<br>> > chicken::Int}<br>><br>> >data BarT = BarT{<br>> > foo :: Int}<br>><br>> Then I can type deFrog correctly.<br>><br>> >deFrog :: FrogT -> String<br>> >deFrog (FrogT s _) = s<br>><br><br>I'm curious as to what you find ugly about this. It appears you need to <br>distinguish between Bars and Frogs, so making them separate types (and <br>having a 3rd type representing the union) is a natural haskell solution:<br><br> data Bar = ..<br> data Frog = ..<br><br> fn1 :: Bar -> ..<br> fn2 :: Frog -> ..<br> fn3 :: Either Bar Frog -> ..<br><br>Perhaps a more concrete example would better illustrate your problem?<br><br>Tim<br><br><br><br><br><br>_______________________________________________<br>Haskell-Cafe mailing list<br>Haskell-Cafe@haskell.org<br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a></blockquote></body></html>