#4809: MonoLocalBinds and type classes cause infinite loop
---------------------------------+------------------------------------------
Reporter: JeremyShaw | Owner:
Type: bug | Status: merge
Priority: normal | Milestone:
Component: Compiler | Version: 7.0.1
Keywords: | Testcase: typecheck/should_run/T4809
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
---------------------------------+------------------------------------------
Changes (by simonpj):
* status: new => merge
* testcase: => typecheck/should_run/T4809
Comment:
I believe we have now, finally, fixed this.
{{{
Mon Dec 13 09:15:11 PST 2010 [email protected]
* Fix recursive superclasses (again). Fixes Trac #4809.
This patch finally deals with the super-delicate question of
superclases in possibly-recursive dictionaries. The key idea
is the DFun Superclass Invariant (see TcInstDcls):
In the body of a DFun, every superclass argument to the
returned dictionary is
either * one of the arguments of the DFun,
or * constant, bound at top level
To establish the invariant, we add new "silent" superclass
argument(s) to each dfun, so that the dfun does not do superclass
selection internally. There's a bit of hoo-ha to make sure that
we don't print those silent arguments in error messages; a knock
on effect was a change in interface-file format.
A second change is that instead of the complex and fragile
"self dictionary binding" in TcInstDcls and TcClassDcl,
using the same mechanism for existential pattern bindings.
See Note [Subtle interaction of recursion and overlap] in TcInstDcls
and Note [Binding when looking up instances] in InstEnv.
Main notes are here:
* Note [Silent Superclass Arguments] in TcInstDcls,
including the DFun Superclass Invariant
Main code changes are:
* The code for MkId.mkDictFunId and mkDictFunTy
* DFunUnfoldings get a little more complicated;
their arguments are a new type DFunArg (in CoreSyn)
* No "self" argument in tcInstanceMethod
* No special tcSimplifySuperClasss
* No "dependents" argument to EvDFunApp
IMPORTANT
It turns out that it's quite tricky to generate the right
DFunUnfolding for a specialised dfun, when you use SPECIALISE
INSTANCE. For now I've just commented it out (in DsBinds) but
that'll lose some optimisation, and I need to get back to
this.
M ./compiler/basicTypes/Id.lhs -3 +8
M ./compiler/basicTypes/IdInfo.lhs -7 +14
M ./compiler/basicTypes/MkId.lhs -12 +24
M ./compiler/coreSyn/CoreFVs.lhs -1 +1
M ./compiler/coreSyn/CoreSubst.lhs -1 +3
M ./compiler/coreSyn/CoreSyn.lhs -9 +23
M ./compiler/coreSyn/CoreTidy.lhs -1 +1
M ./compiler/coreSyn/CoreUnfold.lhs -4 +6
M ./compiler/coreSyn/CoreUtils.lhs -1 +1
M ./compiler/coreSyn/PprCore.lhs -2 +6
M ./compiler/deSugar/DsBinds.lhs -29 +15
M ./compiler/hsSyn/HsBinds.lhs -4 +1
M ./compiler/hsSyn/HsExpr.lhs-boot +4
M ./compiler/hsSyn/HsPat.lhs-boot +1
M ./compiler/iface/BinIface.hs -2 +13
M ./compiler/iface/IfaceSyn.lhs -8 +7
M ./compiler/iface/MkIface.lhs -2 +2
M ./compiler/iface/TcIface.lhs -3 +6
M ./compiler/main/TidyPgm.lhs -1 +1
M ./compiler/simplCore/Simplify.lhs -1 +1
M ./compiler/typecheck/Inst.lhs -3 +11
M ./compiler/typecheck/TcClassDcl.lhs -17 +7
M ./compiler/typecheck/TcDeriv.lhs -21 +22
M ./compiler/typecheck/TcEnv.lhs -2 +2
M ./compiler/typecheck/TcErrors.lhs -9 +10
M ./compiler/typecheck/TcHsSyn.lhs -2 +2
M ./compiler/typecheck/TcHsType.lhs -28 +30
M ./compiler/typecheck/TcInstDcls.lhs -143 +178
M ./compiler/typecheck/TcInteract.lhs -3 +2
M ./compiler/typecheck/TcMType.lhs -49 +34
M ./compiler/typecheck/TcSMonad.lhs -5 +3
M ./compiler/typecheck/TcSimplify.lhs -115 +5
M ./compiler/typecheck/TcType.lhs -5 +8
M ./compiler/typecheck/TcUnify.lhs -7 +5
M ./compiler/types/InstEnv.lhs -8 +18
M ./compiler/vectorise/Vectorise/Type/PADict.hs -1 +2
}}}
This needs to merge to stable.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4809#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
