<div dir="ltr">Sorry for the multiple responses. I just wanted to mention that the equivalent guards do not "reduce pattern matching", they just move it around a bit. Pattern matching is fundamental and pretty much everything involved in evaluation desugars to pattern matching eventually.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 7, 2017 at 3:40 PM Rein Henrichs <<a href="mailto:rein.henrichs@gmail.com">rein.henrichs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'll also mention that GHC's exhaustiveness checker will mark the pattern match as exhaustive (since EvenOdd must be either Even or Odd and both cases are given) but warn about the two guards since it doesn't know that they form a dichotomy. You can use `otherwise`, which is just another name for True, to convince GHC that your guards are exhaustive.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 7, 2017 at 3:38 PM Rein Henrichs <<a href="mailto:rein.henrichs@gmail.com" target="_blank">rein.henrichs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Quoting the report[1], "A boolean guard, g, is semantically equivalent to the pattern guard True <- g," which means the answer is "Yes". A boolean guard is equivalent to a pattern match. A predicate involving ==, however, introduces an Eq constraint that would not be required by pattern matching. For a properly equivalent guard, you need to write your predicates using pattern matching</div><div><br></div><div>isEven Even = True</div><div>isEven _ = False</div><div><br></div><div>to avoid the spurious Eq constraint.</div><div><br></div><div>[1] <a href="https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-460003.13" target="_blank">https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-460003.13</a></div></div></blockquote></div></blockquote></div>