#1781: Type equality class leads to non-termination
----------------------------------------+-----------------------------------
    Reporter:  chak                     |        Owner:         
        Type:  bug                      |       Status:  new    
    Priority:  normal                   |    Milestone:         
   Component:  Compiler (Type checker)  |      Version:  6.9    
    Severity:  normal                   |   Resolution:         
    Keywords:                           |   Difficulty:  Unknown
          Os:  Unknown                  |     Testcase:         
Architecture:  Unknown                  |  
----------------------------------------+-----------------------------------
Changes (by chak):

  * severity:  blocker => normal

Comment:

 Replying to [comment:2 guest]:
 > I set the milestone to 6.8.1 and the severity to blocker, and I hope for
 your understanding.  The reason is that at the moment it seems to be
 impossible to implement a HList-like equality test.  At some point you
 need a type equality constraint, either {{{t1 ~ t2}}} or {{{E t1 t2}}}
 (with {{{E}}} being defined as above).  But neither of them works!  The
 latter doesn’t work because of this very bug, the former doesn’t work
 probably because of bug #1754.  So if GHC 6.8.1 is released without this
 bug being fixed I’ll probably have to tell my users (of Grapefruit) that
 they need something like GHC 6.8.0.20070916. :-(

 You may have misunderstood the problem exposed by this bug - maybe my
 explanation just wasn't clear.  The problem is  '''not''' with the
 equality class `E` as such.  It's with this particular use in the
 definition of `plus`, where the signature type contains a type variable
 that is constrained to be a function by the class context.  This is
 something that has '''never''' worked in GHC, so I doubt that it breaks
 any existing code.

 Having said that, maybe you found some other problems with `E`.  Then,
 please document them in a separate bug (if you haven't yet).  In any case,
 this particular bug is surely no blocker, in fact it is fairly obscure and
 I'd doubt anybody is going to run into it.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1781#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to