[GHC] #11316: Too many guards warning causes issues

[GHC]

#11316: Too many guards warning causes issues
-------------------------------------+-------------------------------------
        Reporter:  NeilMitchell      |                Owner:
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by gkaracha):

 Replying to [comment:3 NeilMitchell]:
 > It seems that if the final guard is {{{| otherwise}}} you could short-
 circuit the entire analysis pass, since we immediately know what the
 result is going to be. In such circumstances, emitting a warning about a
 failed analysis which could be trivially avoided seems unnecessary. It
 would also provide a simple way for users with "excessively complex"
 guards to disable the warning, simply add {{{| otherwise -> error "GHC
 can't cope with this many guards"}}}. No need for the pragma then.

 Hmmmm, I disagree with this:
 The check is not about exhaustiveness only but also about coverage
 (redundancy) checking, which
 is by the way the **expensive** part (both problems are NP-Hard but
 coverage checking appears
 to trigger exponential behaviour much more often). Hence, having an
 `otherwise` means that the
 check is exhaustive but it does not mean that everything is useful:
 {{{#!hs
 len x | []     <- x = 0
       | (_:ys) <- x = 1 + len ys
       | otherwise   = error "can't happen"
 }}}
 Of course the above is exhaustive but it would be nice to see that the
 last guard is redundant.
 Since we cannot see that a specific guard is redundant (we can only check
 for redundant
 clauses), I see your point. But in principle I always think about
 coverage/exhaustiveness
 inseparably.

 Additionally, in terms of the implementation, I would not like to have so
 many "special cases",
 because it becomes really fast unintuitive for the user. What I mean is
 that I would prefer
 the warning about too many guards to appear or not independently of the
 existence of the
 `otherwise` clause.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11316#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler