<p>To clarify, by hack I meant that it seemed like a workaround specifically to keep "case" in the OP's code, when it seemed like they were looking for the functionality of guards.</p>
<p>amindfv / Tom</p>
<div class="gmail_quote">On Dec 11, 2011 1:39 PM, "Yitzchak Gale" <<a href="mailto:gale@sefer.org">gale@sefer.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Brandon Allbery wrote:<br>
>>> > case () of<br>
>>> > () | s == reverse s -> putStrLn "palindrome"<br>
>>> > _ -> putStrLn "nope"<br>
<br>
Tom Murphy wrote:<br>
>> This is kind of a hack of case, though. I think what the OP was looking<br>
>> for is<br>
>> isPalindrome word<br>
>> | (word == reverse word) = putStrLn (word ++ " is a palindrome")<br>
>> | otherwise = putStrLn (word ++ " is not a palindrome")<br>
<br>
> Erm? It's as much of a hack of case as yours is, since the above is<br>
> actually using case.<br>
<br>
I agree with Tom here. While it's true that the compiler<br>
internally desugars to case, that low-level compiler<br>
transformation doesn't have much to do with the<br>
best way to write clear code.<br>
<br>
I find that case often creates code that is more<br>
confusing and bug-prone. Except when what I<br>
really want to express is pattern matching, *and*<br>
there is some specific reason here why I don't<br>
want to use a named function in a let or where<br>
binding. Altogether, it doesn't come up very often<br>
for me.<br>
<br>
And even for styles that use case more than I<br>
do, certainly there is room to call the use of<br>
the "case ()" idiom a hack. (Even though I'll<br>
admit that I do use it sometimes.)<br>
<br>
Regards,<br>
Yitz<br>
</blockquote></div>