[GHC] #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind

[GHC]

#11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat,
but can for equivalent type family operating on user-defined Nat kind
-------------------------------------+-------------------------------------
        Reporter:  duairc            |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       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 duairc):

 Could it not be possible to introduce some way of pattern-matching on
 {{{GHC.TypeLits}}}'s {{{Nat}}}s independently of generalised injectivity?
 Maybe it's a question that would involve a lot of bikeshedding... but
 surely the compiler ultimately has enough information to prove that
 {{{Replicate}}} is injective, I just can't destructure type-level
 {{{Nat}}}s. Could there be a magic built-in pattern synonym {{{Succ}}} for
 {{{Nat}}}s? Can pattern synonyms work on the type level? I don't really
 know much about the internals to know how to implement that, but there
 must be a way.

 Like if full generalised injectivity is just around the corner, then maybe
 we should just wait for that, but from what I've read it sounds like there
 are still a lot of kinks that need to be worked out first and it might
 turn out to be too difficult altogether? Right now pretty much every
 package that does type-level stuff defines its own {{{Nat}}} type, and I'd
 imagine the lack of the ability to pattern match on {{{GHC.TypeLits}}}'s
 {{{Nat}}} is a big part of the reason for that.

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