Generalized type-defaulting rules

Question

Haskell's type-defaulting rules defaults a type variable a with constraints (C1 a,...,Cn a) if:

The type variable a appears in no other constraints
All the classes Ci are standard.
At least one of the classes Ci is numeric

This makes sense to me but it's also very limited: in practice it means that you always have to specify the type when it is ambiguous when you work with custom classes. For example, this doesn't compile:

class (Show a) => MyShow a where
    myShow :: a -> String
    myShow = show

instance (MyShow a) => MyShow (Maybe a) where
    myShow Nothing = "Nothing"
    myShow (Just x) = "Just " ++ (myShow x)

main = print $ myShow Nothing -- ambiguous

GHCi extends this set of rules in this way:

All of the classes Ci are single-parameter type classes.
At least one of the classes Ci is numeric, or is Show, Eq, or Ord.

and GHC has an extension called ExtendedDefaultRules that enable these rules. However this extension is very specific: it works only on GHC and with standard classes. For instance, one can think about libraries that don't use the standard library. In that case, the GHCi extension won't work.

My question is: the only way to extend the Haskell's type-defaulting rules like GHCi does is with compiler extensions? And more generic: is there a way to define type-defaulting based on some rules on the constraints in Haskell 98?

There's no way to do what you want. If you can come up with a good design, we are all ears. The current type defaulting is a wart. — augustss
Something like: instance (MyShow a) => MyShow (Maybe a) where .... defaulting (Int) . The compiler can check if the type is ambiguous and in that case default. In the case above Nothing would have type Maybe Int. Of course you can default only on types that satisfy the constraints. — mariop
@mariop I understand that you're excited about this idea, but at the moment it seems a bit half-baked. There's a lot to think about, like: What should you do if there are many constraints that all have different defaults? How can library users affect a library's defaulting choices to closer fit their needs? Why are instances the canonical right place to attach defaulting instructions? Can your solution be generalized to multi-parameter type classes (and fundeps, and type families)? I'm sure there are many other difficult questions that a complete proposal would need to address, too. — Daniel Wagner
It was just a 5 minutes idea, nothing realistic. I'm not excited about it. My idea with this post was to understand better the problem and how to solve this limitation, not to propose a solution to it. Thank to both for the answers. — mariop
This proposes to extend these rules: github.com/ghc-proposals/ghc-proposals/pull/409 — Joachim Breitner

augustss augustss · Accepted Answer · 2013-07-24T18:51:34

There is no way to do what you want.

The current situation is impoverished by design. The idea was to do something minimal that could be extended in the future when we have a good design.

Generalized type-defaulting rules

1 Answers