GHC: Ticket #2853: Defaulting not used enough with type families
http://ghc.haskell.org/trac/ghc/ticket/2853
<p>
Consider this module
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies, ExtendedDefaultRules #-}
module Bug3 where
class C t where
type T t
instance C Integer where
type T Integer = Integer
data (C t, Num t) => D t = D (T t)
instance Show (D a) where show _ = ""
</pre><p>
Now let's try to ask for the type of (D 5)
</p>
<pre class="wiki">*Bug3> :t D 5
D 5 :: (Num (T t), C t, Num t) => D t
</pre><p>
That's great. Now if we try to show this value it should have type
</p>
<pre class="wiki">(Num (T t), C t, Num t) => String
</pre><p>
And now the defaulting mechanism should set t to Integer, which would resolve the rest of the context. But instead we get this:
</p>
<pre class="wiki">*Bug3> :t show (D 5)
<interactive>:1:8:
No instance for (Num (T t))
arising from the literal `5' at <interactive>:1:8
Possible fix: add an instance declaration for (Num (T t))
In the first argument of `D', namely `5'
In the first argument of `show', namely `(D 5)'
In the expression: show (D 5)
</pre><p>
It looks like the defaulting never got used.
</p>
en-usGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/ticket/2853
Trac 1.2.2.dev0guestMon, 08 Dec 2008 12:09:49 GMTcc set
http://ghc.haskell.org/trac/ghc/ticket/2853#comment:1
http://ghc.haskell.org/trac/ghc/ticket/2853#comment:1
<ul>
<li><strong>cc</strong>
<em>lennart@…</em> added
</li>
</ul>
TicketchakTue, 09 Dec 2008 01:48:48 GMTowner set
http://ghc.haskell.org/trac/ghc/ticket/2853#comment:2
http://ghc.haskell.org/trac/ghc/ticket/2853#comment:2
<ul>
<li><strong>owner</strong>
set to <em>chak</em>
</li>
</ul>
<p>
No, defaulting is not used, but I also <strong>don't</strong> think it should be used in this example. The Haskell Report says:
"[...]an ambiguous type variable, v, is defaultable if:
</p>
<ul><li>v appears only in constraints of the form C v, where C is a class, and
</li><li>at least one of these classes is a numeric class, (that is, Num or a subclass of Num), and
</li><li>all of these classes are defined in the Prelude or a standard library"
</li></ul><p>
The above code clearly violates the third condition (<code>C</code> is not a standard class).
</p>
<p>
However, I think, we should discuss what would happen for this program:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies, ExtendedDefaultRules #-}
module Bug3 where
class C t where
type T t
instance C Integer where
type T Integer = Integer
data (Num t) => D t = D (T t)
instance Show (D a) where show _ = ""
</pre><p>
Now, we get (without defaulting): <code>(Num (T t), Num t) => String</code>.
</p>
<p>
Literally speaking, this still violates the first condition from the Haskell Report. However, you might argue that -in the presence of type families- we should generalise the definition of the Report to permit classes of the form <code>C (T v1..vn))</code> in contexts to which the default rules applies.
</p>
<p>
SimonPJ, what do you think?
</p>
TicketguestTue, 09 Dec 2008 09:01:45 GMT
http://ghc.haskell.org/trac/ghc/ticket/2853#comment:3
http://ghc.haskell.org/trac/ghc/ticket/2853#comment:3
<p>
The point of ExtendedDefaultRules is to get away from the draconian Haskell-98 rules.
The one that is especially annoying is that all classes have to be standard ones (that rules should be removed for Haskell', I think).
</p>
<p>
I'm not sure why the rules insist on only the form (C v). If there's some technical reason for this I guess I'm out of luck.
</p>
TicketsimonpjTue, 09 Dec 2008 09:21:27 GMTstatus changed; difficulty, resolution set
http://ghc.haskell.org/trac/ghc/ticket/2853#comment:4
http://ghc.haskell.org/trac/ghc/ticket/2853#comment:4
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>closed</em>
</li>
<li><strong>difficulty</strong>
set to <em>Unknown</em>
</li>
<li><strong>resolution</strong>
set to <em>duplicate</em>
</li>
</ul>
<p>
But see <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2641" title="#2641: feature request: Revise the rules for -XExtendedDefaultRules (new)">#2641</a> which argues for making the rules <em>less</em> liberal, not more liberal.
</p>
<p>
This is a usability issue, not a technical one. If you care enough to drive a discussion (perhaps on ghc-users) to a consensus, I'd be happy to implement the outcome.
</p>
<p>
Rather than have two tickets about the semantics of <code>ExtendedDefaultRules</code>, I'll close this ticket and link to it from <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2641" title="#2641: feature request: Revise the rules for -XExtendedDefaultRules (new)">#2641</a>.
</p>
<p>
Simon
</p>
<p>
(PS: also related: <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1877" title="#1877: task: Change the meaning of -fextended-default-rules (closed: fixed)">#1877</a>.)
</p>
Ticket