GHC: Ticket #8030: FlexibleContexts PolyKinds Type Families bug
http://ghc.haskell.org/trac/ghc/ticket/8030
<p>
A bug with TypeFamilies + FlexibleContexts + PolyKinds
</p>
<pre class="wiki">{-# LANGUAGE PolyKinds, FlexibleContexts, TypeFamilies #-}
class Monoid (a :: k) where
type Pr a :: *
mempty :: Pr a
mappend :: Pr a -> Pr a -> Pr a
instance Monoid [b] where
type Pr [b] = [b]
mempty = []
mappend = (++)
</pre><p>
This is compilable.
But this is not:
</p>
<pre class="wiki">t :: (Monoid [b]) => b -> [b]
t b = [b] `mappend` mempty
</pre><pre class="wiki"> Could not deduce ([b] ~ Pr k0 a0)
from the context (Monoid * [b])
bound by the type signature for t :: Monoid * [b] => b -> [b]
at t.hs:26:6-29
The type variables `k0', `a0' are ambiguous
Possible fix: add a type signature that fixes these type variable(s)
In the expression: [b] `mappend` mempty
In an equation for `t': t b = [b] `mappend` mempty
Could not deduce (Pr k1 a1 ~ [b])
from the context (Monoid * [b])
bound by the type signature for t :: Monoid * [b] => b -> [b]
at test4.hs:26:6-29
The type variables `k1', `a1' are ambiguous
Possible fix: add a type signature that fixes these type variable(s)
Expected type: Pr k0 a0
Actual type: Pr k1 a1
In the second argument of `mappend', namely `mempty'
In the expression: [b] `mappend` mempty
In an equation for `t': t b = [b] `mappend` mempty
</pre>en-usGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/ticket/8030
Trac 1.0.1goldfireTue, 02 Jul 2013 20:46:11 GMTstatus changed; resolution set
http://ghc.haskell.org/trac/ghc/ticket/8030#comment:1
http://ghc.haskell.org/trac/ghc/ticket/8030#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>invalid</em>
</li>
</ul>
<p>
This looks like correct behavior to me.
</p>
<p>
The problem is that the type signatures for <tt>mempty</tt> and <tt>mappend</tt> are inherently ambiguous. Because GHC cannot know whether <tt>Pr</tt> is injective, there is no way to get the identity of the type <tt>a</tt> from the identity of <tt>Pr a</tt>. Thus, all uses of <tt>mempty</tt> and <tt>mappend</tt> will be ambiguous. This ambiguity is what is causing the error you see.
</p>
<p>
It's possible that the definitions of <tt>mempty</tt> and <tt>mappend</tt> as given should be rejected, but the error you're seeing looks correct to me.
</p>
TicketjstolarekThu, 26 Mar 2015 13:30:17 GMTrelated set
http://ghc.haskell.org/trac/ghc/ticket/8030#comment:2
http://ghc.haskell.org/trac/ghc/ticket/8030#comment:2
<ul>
<li><strong>related</strong>
set to <em>#8034</em>
</li>
</ul>
TicketthomieThu, 26 Mar 2015 14:29:42 GMT
http://ghc.haskell.org/trac/ghc/ticket/8030#comment:3
http://ghc.haskell.org/trac/ghc/ticket/8030#comment:3
<p>
Fixed in HEAD, probably in commit <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/f66e0e695b0377c469fbe877d4850fc0ebca2010/ghc" title="A raft of small changes associated with -XConstrainedClassMethods
See ...">f66e0e695b0377c469fbe877d4850fc0ebca2010</a>:
</p>
<pre class="wiki">Author: Simon Peyton Jones <>
Date: Wed Mar 4 11:59:47 2015 +0000
A raft of small changes associated with -XConstrainedClassMethods
See Trac #7854. Specifically:
* Major clean up and simplification of check_op in checkValidClass;
specifically
- use checkValidType on the entire method-selector type to detect
ambiguity
- put a specific test for -XConstrainedClassMethods
* Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses
(a bit ad-hoc but see #7854), and document in the user manual.
* Do the checkAmbiguity test just once in TcValidity.checkValidType,
rather than repeatedly at every level. See Note [When to call checkAmbiguity]
* Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous.
(It's a rather magic function.)
* Improve location info for check_op in checkValidClass
* Update quite a few tests, which had genuinely-ambiguous class
method signatures. Some I fixed by making them unambiguous; some
by adding -XAllowAmbiguousTypes
</pre><p>
Now always shows the same ambiguity error. Needs a regression test before closing.
</p>
Ticket