[GHC] #14316: Precedence of type-level operators

[GHC]

#14316: Precedence of type-level operators
-------------------------------------+-------------------------------------
        Reporter:  lspitzner         |                Owner:  (none)
            Type:  feature request   |               Status:  closed
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      Resolution:  duplicate         |             Keywords:  precedence
                                     |  TypeOperators DataKinds
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #10056, #10059,   |  Differential Rev(s):
  #10431                             |
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by RyanGlScott):

 * status:  new => closed
 * resolution:   => duplicate
 * related:   => #10056, #10059, #10431


Comment:

 There are two questions here:

 1. What are the precedences of data constructors that are promoted to
 types via `DataKinds`?

    This has a simple answer: they have the same precedences as their
 value-level counterparts. Since `(:)` is `infixr 5` at the value level,
 `'(:)` is also `infixr 5` at the type level.

 2. What is the precedence of `(~)`?

    Alas, this is a simple question with an ugly answer. For unfortunate
 historical reasons, `(~)` is not a proper type operator, but rather a
 specially parsed symbol that happens to //look// like a type operator. As
 such, it does not have a well defined precedence (#10056), and you can't
 even ask GHCi for its precedence with `:info` (#10059).

    This is obviously not a great situation, since it leads to all sorts of
 confusing parser oddities like the one observed here. The plan laid out in
 #10056 will hopefully make the story a little more palatable. The plan is
 (roughly):

      * Remove as much special treatment for `(~)` from the parser as
 possible
      * Define `(~)` as a plain old type operator somewhere in `base`. For
 backwards compatibility purposes, this will probably need to always be in
 scope (otherwise, it'd be possible to hide it via Haskell's module system,
 which is something that you can't do with `(~)` today).
      * Give `(~)` a precedence of `infix -1` (i.e., lower than `(->)`).
      * Enable the use of `(~)` via a new language extension
 (`-XEqualityConstraints` has been proposed in #10431). For backwards
 compatibility, `-XGADTs` and `-XTypeFamilies` would also continue to allow
 the use of `(~)`.

 Given that this ticket is essentially just a symptom of #10056, I'll close
 this as a duplicate in favor of #10056.

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