Opened 8 years ago

Closed 3 years ago

#1702 closed bug (fixed)

type operator precedences don't work in contexts

Reported by: b.hilken@… Owned by:
Priority: lowest Milestone: 7.6.2
Component: Compiler Version: 6.8
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description (last modified by simonpj)

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.

Change History (16)

comment:1 Changed 8 years ago by simonpj

  • Description modified (diff)

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

comment:2 Changed 8 years ago by simonpj

  • Description modified (diff)

comment:3 Changed 8 years ago by igloo

  • Milestone set to 6.1

comment:4 Changed 8 years ago by simonpj

See also #1727

comment:5 Changed 8 years ago by simonmar

  • Architecture changed from powerpc to Multiple
  • Operating System changed from MacOS X to Multiple

comment:6 Changed 7 years ago by simonmar

  • Architecture changed from Multiple to Unknown/Multiple

comment:7 Changed 7 years ago by simonmar

  • Operating System changed from Multiple to Unknown/Multiple

comment:8 Changed 6 years ago by igloo

  • Milestone changed from 6.10 branch to 6.12 branch

comment:9 Changed 5 years ago by igloo

  • Milestone changed from 6.12 branch to 6.12.3

comment:10 Changed 5 years ago by igloo

  • Milestone changed from 6.12.3 to 6.14.1
  • Priority changed from normal to low

comment:11 Changed 5 years ago by igloo

  • Milestone changed from 7.0.1 to 7.0.2

comment:12 Changed 4 years ago by igloo

  • Milestone changed from 7.0.2 to 7.2.1

comment:13 Changed 4 years ago by igloo

  • Milestone changed from 7.2.1 to 7.4.1

comment:14 Changed 4 years ago by igloo

  • Milestone changed from 7.4.1 to 7.6.1
  • Priority changed from low to lowest

comment:15 Changed 3 years ago by igloo

  • Milestone changed from 7.6.1 to 7.6.2

comment:16 Changed 3 years ago by monoidal

  • Resolution set to fixed
  • Status changed from new to closed
  • Type of failure set to None/Unknown

The code works fine in 7.6, with a minor change (type operators now do not use colons). It might have been fixed when constraint kinds were added. I opened #7609 to note a minor formatting error.

{-# LANGUAGE TypeOperators, MultiParamTypeClasses, FlexibleContexts #-}
data (=:) a b
data (+:) a b
class Disjoint a b

infixr 4 =:
infixl 3 +:
infix 2 `Disjoint`

labelZip :: (n =: a `Disjoint` m =: b)
         => n -> m -> [a] -> [b] -> [n =: a +: m =: b]
labelZip = undefined
Note: See TracTickets for help on using tickets.