<html><body>I'd have to say that there is one(and only one) issue in Haskell 
that 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
 things correctly.<br><br>Say we have a <br><br>&gt;data BadFoo =<br>&gt; 
BadBar{<br>&gt;&nbsp; badFoo::Int} |<br>&gt; BadFrog{<br>&gt;&nbsp; 
badFrog::String,<br>&gt;&nbsp; badChicken::Int}<br><br>This is fine, until we 
want to write a function that acts on Frogs but not on Bars.&nbsp; The best we
 can do is throw a runtime error when passed a Bar and not a 
Foo:<br><br>&gt;deBadFrog :: BadFoo -&gt; String<br>&gt;deBadFrog (BadFrog s 
_) = s<br>&gt;deBadFrog BadBar{}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = error "Error:
 This is not a frog."<br><br>We cannot type our function such that it only 
takes Frogs and not Bars.&nbsp; This makes what should be a trivial compile 
time error into a nasty runtime one :(<br><br>The only solution I have found 
to this is a rather ugly one:<br><br>&gt;data Foo = Bar BarT | Frog 
FrogT<br><br>If I then create new types for each data 
constructor.<br><br>&gt;data FrogT = FrogT{<br>&gt; frog::String,<br>&gt; 
chicken::Int}<br><br>&gt;data BarT = BarT{<br>&gt; foo :: Int}<br><br>Then I 
can type deFrog correctly.<br><br>&gt;deFrog :: FrogT -&gt; 
String<br>&gt;deFrog (FrogT s _) = s<br><br>But it costs us much more code to 
do it correctly.&nbsp; I've never seen it done 
correctly.&nbsp; It's just too ugly to do it right :/ and for no good 
reason.&nbsp; It seems to me, that it was a design mistake to make data 
constructors and types as different entities and this is not something I know 
how to fix easily with the number of lines of Haskell code in existence today 
:/<br><br>&gt;main = do<br>&gt; frog &lt;- return (Frog (FrogT "Frog" 
42))<br>&gt; print $<br>&gt;&nbsp; case frog of<br>&gt;&nbsp;&nbsp; (Frog 
myFrog) -&gt; deFrog myFrog<br>&gt; badFrog &lt;- return (BadBar 4)<br>&gt; 
print $<br>&gt;&nbsp; case badFrog of<br>&gt;&nbsp;&nbsp; (notAFrog@BadBar{}) 
-&gt; deBadFrog notAFrog<br><br>The ease with which we make bad design choices
 and write bad code(in this particular case) is tragically astounding.<br>
<br>Any suggestions on how the right way could be written more cleanly are 
very welcome!<br><br>Timothy Hobbs<br></body></html>