case statement and guarded equations

In the case statement for the half function I think variable m is bound to the value of (snd (half (n - 1)). With this assumption, I have have written a guarded version called half1. Is it always possible to write case statements as a set of conditional equations? My intuition is that this should be possible and that the guarded version reduces pattern matching? Thanks, Pat data EvenOdd = Even | Odd deriving (Show,Eq) half 0 = (Even,0) half n = case half (n-1) of (Even,m) -> (Odd,m) (Odd,m) -> (Even,m+1) half1 0 = (Even , 0) half1 n | (fst (half (n - 1)) == Even) = (Odd , (snd (half (n - 1)))) half1 n | (fst (half (n - 1)) == Odd) = (Even , ((snd (half (n - 1))) + 1)) -- This email originated from DIT. If you received this email in error, please delete it from your system. Please note that if you are not the named addressee, disclosing, copying, distributing or taking any action based on the contents of this email or attachments is prohibited. www.dit.ie Is ó ITBÁC a tháinig an ríomhphost seo. Má fuair tú an ríomhphost seo trí earráid, scrios de do chóras é le do thoil. Tabhair ar aird, mura tú an seolaí ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon chóipeáil, aon dáileadh nó ar aon ghníomh a dhéanfar bunaithe ar an ábhar atá sa ríomhphost nó sna hiatáin seo. www.dit.ie Tá ITBÁC ag aistriú go Gráinseach Ghormáin – DIT is on the move to Grangegorman http://www.dit.ie/grangegorman

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 isEven Even = True isEven _ = False to avoid the spurious Eq constraint. [1] https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-460003.1...

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.
On Fri, Jul 7, 2017 at 3:38 PM Rein Henrichs
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
isEven Even = True isEven _ = False
to avoid the spurious Eq constraint.
[1] https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-460003.1...

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.
On Fri, Jul 7, 2017 at 3:40 PM Rein Henrichs
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.
On Fri, Jul 7, 2017 at 3:38 PM Rein Henrichs
wrote: 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
isEven Even = True isEven _ = False
to avoid the spurious Eq constraint.
[1] https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-460003.1...
participants (2)
-
PATRICK BROWNE
-
Rein Henrichs