[GHC] #12025: Order of constraints forced (in pattern synonyms, type classes in comments)

[GHC]

#12025: Order of constraints forced (in pattern synonyms, type classes in comments)
-------------------------------------+-------------------------------------
        Reporter:  Iceland_jack      |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  8.1
  checker)                           |             Keywords:
      Resolution:                    |  TypeApplications PatternSynonyms
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  11513, 10928      |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 This ordering problem is very apparent in GADT definitions. If you say

 {{{#!hs
 data X b where
   MkX :: forall a b. a -> b -> X b
 }}}

 you get `MkX :: forall b a. a -> b -> X b`. See the last bullet
 [https://downloads.haskell.org/~ghc/8.0.1-rc4/docs/html/users_guide/glasgow_exts.html
 #visible-type-application in the manual].

 It would be straightforward, syntactically, to fix this for GADTs. The
 implementation is a bit more involved, because GHC assumes that universals
 come before existentials. This is surmountable with some engineering.

 We should consider this problem in concert with allowing visible type
 patterns (#11350), because we want patterns to be able to match
 existentials but not universals. It's very unclear how to do this in a way
 that will be sane to users.

 I don't have a good idea for a new syntax for dealing with this in pattern
 synonyms.

 As for classes, I'm not as bothered. The workaround is straightforward.
 Furthermore, we don't currently give full type signatures for class
 methods, always leaving off the class constraint. (I don't see how #11620
 relates to this.)

 If we are going to be bothered about classes, we should also be bothered
 about record seleectors. But I vote not to be bothered about anything
 except data constructors and pattern synonyms.

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