[GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker

[GHC]

#11303: Pattern matching against sets of strings sharing a prefix blows up pattern
checker
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:  T11303
      Blocked By:                    |             Blocking:
 Related Tickets:  #11302            |  Differential Rev(s):  Phab:D1716,
       Wiki Page:                    |  Phab:D1719
-------------------------------------+-------------------------------------

Comment (by gkaracha):

 Oh, yes, this is rather expected. I added a note in `deSugar/Check.hs`
 about the general case:
 `Note [Translate CoPats]`. As the note says, a `CoPat` is translated as
 follows:
 {{{
   pat |> co    ===>    x (pat <- (x |> co))
 }}}
 In the latest commit
 [changeset:"0acdcf2482d24903b504e6b34fa745ef855ff00d/ghc" 0acdcf24/ghc], I
 added two cases when translating `CoPat`s:
  * If `co` is refl we can drop it and do not generate the guard
  * If `co` is just a hole, we can also drop it.
 So, as the commit message says, we now generate **less** guards. For data
 families, this
 coercion is essential, because changes the representation tycon to the
 source tycon and I
 cannot drop it, that is, without changing the type of the pattern. The
 previous examples had
 `CoPat`s due to inference but your example above uses data families
 directly so the workaround
 does not apply. I can only hope that I will be able to come up with a
 better translation for
 `CoPat`s before the release but I do not know how to address this yet.

 Btw, I think we should move this whole discussion to #11276 since #11303
 is rather irrelevant.

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