GHC: Ticket #1050: Using an inferred type as a type signature fails
http://ghc.haskell.org/trac/ghc/ticket/1050
<p>
See the thread starting here
<a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2006-December/011714.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2006-December/011714.html</a>.
Here's a short example:
</p>
<pre class="wiki">class C a b where
op :: a -> a
-- f :: C a b => a -> a
f x = op x
</pre><p>
It doesn't get much simpler than that! With the type sig, GHC can't see that the <code>(C a b)</code> provided can satisfy the <code>(C a b1)</code> which arises from the call to op. However, without the constraint, GHC simply abstracts over the constrains arising in the RHS, namely <code>(C a b1)</code>, and hence infers the type
</p>
<pre class="wiki"> f :: C a b1 => a -> a
</pre><p>
It is extremely undesirable that the inferred type does not work as a type signature, but I don't see how to fix it easily. It doesn't affect many programs, I think; hence low priority
</p>
en-usGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/ticket/1050
Trac 1.2simonpjFri, 15 Dec 2006 17:46:29 GMT
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:1
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:1
<p>
See also Oleg's message <a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2006-December/020538.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2006-December/020538.html</a>
</p>
TicketguestWed, 18 Jul 2007 01:08:53 GMTcc set
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:2
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:2
<ul>
<li><strong>cc</strong>
<em>a.dcolour@…</em> added
</li>
</ul>
<p>
I'm interested in the resolution of this. Added to CC.
</p>
TicketsimonmarTue, 30 Sep 2008 15:37:42 GMTarchitecture changed
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:3
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:3
<ul>
<li><strong>architecture</strong>
changed from <em>Unknown</em> to <em>Unknown/Multiple</em>
</li>
</ul>
TicketsimonmarTue, 30 Sep 2008 15:52:05 GMTos changed
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:4
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:4
<ul>
<li><strong>os</strong>
changed from <em>Unknown</em> to <em>Unknown/Multiple</em>
</li>
</ul>
TicketmorabbinMon, 21 Jan 2013 03:17:56 GMTfailure set
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:5
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:5
<ul>
<li><strong>failure</strong>
set to <em>None/Unknown</em>
</li>
</ul>
<p>
Defect still present in GHC 7.6.1, but I'm seeing some oddness in the number of errors presented with multiples:
</p>
<pre class="wiki">{-# LANGUAGE MultiParamTypeClasses #-}
class C a b where
op :: a -> a
f1 :: C a b => a -> a
f1 x = op x
f2 :: C a b => a -> a
f2 x = op x
</pre><p>
If we give both type signatures, both fail. If we give neither, both fail (albeit with a different error). Leave out only <em>one</em> type signature, and only that function fails to type. Or, more likely, the other failure is not reported.
</p>
<p>
I have files to attach if deemed worthwhile (no patch, just files that show the four behaviors).
</p>
TicketsimonpjTue, 22 Jan 2013 17:24:55 GMTstatus changed; resolution set
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:6
http://ghc.haskell.org/trac/ghc/ticket/1050#comment:6
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
<p>
GHC always checks each type signature for ambiguity; if that faile, it just stops, since ambiguous signatures can lead to futher errors. If there are no sigatures, it goes ahead and tries to typecheck both defns, finding an ambiguous inferred type for each.
</p>
<p>
It's not perfect, but I think it's good enough.
</p>
<p>
Simon
</p>
Ticket