type operator precedences don't work in contexts

[b.hilken@…]

Type contexts don't parse correctly when a type class is used infix. The following example:

>    infixr 4 :=:
>    infixl 3 :+:
>    infix 2 `Disjoint`
>
>    labelZip :: (n :=: a `Disjoint` m :=: b) 
>             => n -> m -> [a] -> [b] -> [n :=: a :+: m :=: b]

gives the error:

    Type constructor `:=:' used as a class
    In the type `(:=: n (a Disjoint (m :=: b))) =>
                 n -> m -> [a] -> [b] -> [(n :=: a) :+: (m :=: b)]'
    In the type signature for `labelZip':
      labelZip :: (:=: n (a Disjoint (m :=: b))) =>
                  n -> m -> [a] -> [b] -> [(n :=: a) :+: (m :=: b)]

where the parenthesised version works.

[simonpj]

Absolutely right, good report.

It's really a structural flaw with historical origins. Infix expressions (including types) are sorted out by the renamer not the parser. This is a Good Thing. However, before the advent of infixity in types, the parser decides what the class is in the context of a type signature. But with infix stuff, the parser can't do that.

Solution: defer the unravelling of contexts until the renamer, removing it from the parser. I'll get to this but not until after ICFP.

Simon

[simonpj]

See also #1727