[GHC] #2715: Equality constraint in superclass not supported
GHC
cvs-ghc at haskell.org
Wed Jun 22 18:54:11 CEST 2011
#2715: Equality constraint in superclass not supported
-------------------------------------------------+--------------------------
Reporter: rodprice | Owner: chak
Type: task | Status: closed
Priority: low | Milestone: 7.2.1
Component: Compiler (Type checker) | Version: 6.10.1
Resolution: fixed | Keywords:
Testcase: indexed_types/should_compile/T2715 | Blockedby:
Difficulty: Unknown | Os: Linux
Blocking: | Architecture: x86
Failure: None/Unknown |
-------------------------------------------------+--------------------------
Changes (by simonpj):
* status: new => closed
* testcase: => indexed_types/should_compile/T2715
* resolution: => fixed
Comment:
Hurrah! We now have superclass equalities. I've added this example as a
test.
{{{
commit 940d1309e58382c889c2665227863fd790bdb21c
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date: Wed Jun 22 17:37:47 2011 +0100
Add equality superclasses
Hurrah. At last we can write
class (F a ~ b) => C a b where { ... }
This fruit of the fact that equalities are now values,
and all evidence is handled uniformly.
The main tricky point is that when translating to Core
an evidence variable 'v' is represented either as
either Var v
or Coercion (CoVar v)
depending on whether or not v is an equality. This leads
to a few annoying calls to 'varToCoreExpr'.
compiler/basicTypes/MkId.lhs | 4 +-
compiler/deSugar/DsExpr.lhs | 18 +++++++-
compiler/iface/BuildTyCl.lhs | 50 ++++++++++------------
compiler/typecheck/TcInstDcls.lhs | 85
+++++++++++++++++-------------------
compiler/typecheck/TcMType.lhs | 9 +----
compiler/types/Class.lhs | 21 ++++------
6 files changed, 92 insertions(+), 95 deletions(-)
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2715#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list