GHC: Ticket #565: overlapping instances & fundeps broken
http://ghc.haskell.org/trac/ghc/ticket/565
<pre class="wiki">Consider this:
--
class X a
instance X Bool
instance (Num a) => X a
--
For as long as "instance Num Bool" is not declared, the two instances do
not de facto overlap. But that's not immediately obvious to GHC, so it will
complain, at least by default. But I can stop it complaining by passing
-fallow-overlapping-instances, which I interpret as asking GHC to trust me
that instances don't actually overlap.
But consider this, with an added dependent argument:
--
class X a b | a -> b
instance X Bool Bool
instance (Num a) => X a Char
--
Now GHC will complain even with -fallow-overlapping-instances. I believe
this is inappropriate.
So why have the fundep? Well, GHC can still make use of it, and it can still
calculate the dependent type:
--
class X a b | a -> b where
{
foo :: a -> b;
};
instance X Bool Bool where
{
foo a = a;
};
instance (Num a) => X a Char where
{
foo a = 'N';
}
test = foo True;
--
Without the fundep, GHC cannot calculate 'foo True', since 'instance X Bool
Bool' is not general enough. This is correct. But with the fundep, GHC will
complain that it can't prove that the two instances don't conflict for the
fundep, even with -fallow-overlapping-instances.
I submit that GHC with -fallow-overlapping-instances should not complain
in this case.
</pre>en-usGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/ticket/565
Trac 1.2.2iglooThu, 25 Jan 2007 13:31:38 GMTdescription changed; difficulty, os, architecture, milestone set
http://ghc.haskell.org/trac/ghc/ticket/565#comment:1
http://ghc.haskell.org/trac/ghc/ticket/565#comment:1
<ul>
<li><strong>difficulty</strong>
set to <em>Unknown</em>
</li>
<li><strong>description</strong>
modified (<a href="/trac/ghc/ticket/565?action=diff&version=1">diff</a>)
</li>
<li><strong>os</strong>
set to <em>Unknown</em>
</li>
<li><strong>architecture</strong>
set to <em>Unknown</em>
</li>
<li><strong>milestone</strong>
set to <em>_|_</em>
</li>
</ul>
TicketsimonmarTue, 30 Sep 2008 15:37:41 GMTarchitecture changed
http://ghc.haskell.org/trac/ghc/ticket/565#comment:2
http://ghc.haskell.org/trac/ghc/ticket/565#comment:2
<ul>
<li><strong>architecture</strong>
changed from <em>Unknown</em> to <em>Unknown/Multiple</em>
</li>
</ul>
TicketsimonmarTue, 30 Sep 2008 15:52:02 GMTos changed
http://ghc.haskell.org/trac/ghc/ticket/565#comment:3
http://ghc.haskell.org/trac/ghc/ticket/565#comment:3
<ul>
<li><strong>os</strong>
changed from <em>Unknown</em> to <em>Unknown/Multiple</em>
</li>
</ul>
TicketiglooSat, 18 Jul 2009 00:35:05 GMTstatus changed; owner deleted
http://ghc.haskell.org/trac/ghc/ticket/565#comment:4
http://ghc.haskell.org/trac/ghc/ticket/565#comment:4
<ul>
<li><strong>status</strong>
changed from <em>assigned</em> to <em>new</em>
</li>
<li><strong>owner</strong>
<em>nobody</em> deleted
</li>
</ul>
TicketganeshTue, 17 Nov 2009 16:20:29 GMTfailure set
http://ghc.haskell.org/trac/ghc/ticket/565#comment:5
http://ghc.haskell.org/trac/ghc/ticket/565#comment:5
<ul>
<li><strong>failure</strong>
set to <em>None/Unknown</em>
</li>
</ul>
<p>
The problem with all these examples is that someone (in another module) add <code>instance Num Bool</code>, and now the instances really do overlap, and the fundep is violated.
</p>
<p>
So I think this bug should be closed as invalid.
</p>
TicketiglooTue, 17 Nov 2009 18:13:22 GMTowner set
http://ghc.haskell.org/trac/ghc/ticket/565#comment:6
http://ghc.haskell.org/trac/ghc/ticket/565#comment:6
<ul>
<li><strong>owner</strong>
set to <em>simonpj</em>
</li>
</ul>
<p>
I agree; Simon, can you confirm and close it, please?
</p>
TicketsimonpjWed, 18 Nov 2009 14:48:22 GMTstatus, resolution changed
http://ghc.haskell.org/trac/ghc/ticket/565#comment:7
http://ghc.haskell.org/trac/ghc/ticket/565#comment:7
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
changed from <em>None</em> to <em>invalid</em>
</li>
</ul>
<p>
I agree. And in any case we want to encourage people to move towards type functions, partly because questions like this are pretty tricky.
</p>
<p>
Simon
</p>
Ticket