Changes between Initial Version and Version 1 of Ticket #1702


Ignore:
Timestamp:
Sep 17, 2007 1:04:17 PM (7 years ago)
Author:
simonpj
Comment:

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

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1702 – Description

    initial v1  
    11Type contexts don't parse correctly when a type class is used infix. The following example: 
    2  
     2{{{ 
    33>    infixr 4 :=: 
    44>    infixl 3 :+: 
     
    66> 
    77>    labelZip :: (n :=: a `Disjoint` m :=: b) => n -> m -> [a] -> [b] -> [n :=: a :+: m :=: b] 
    8  
     8}}} 
    99gives the error: 
    10  
     10{{{ 
    1111    Type constructor `:=:' used as a class 
    1212    In the type `(:=: n (a Disjoint (m :=: b))) => 
     
    1515      labelZip :: (:=: n (a Disjoint (m :=: b))) => 
    1616                  n -> m -> [a] -> [b] -> [(n :=: a) :+: (m :=: b)] 
    17  
     17}}} 
    1818where the parenthesised version works.