[Haskell-cafe] Re: What does the Haskell type system do with "show (1+2)"?

[Cale Gibbard]

On 13/01/06, Daniel Fischer <daniel.is.fischer at web.de> wrote:
> Am Freitag, 13. Januar 2006 11:12 schrieb Christian Maeder:
> > Jared Updike wrote:
> > > http://www.haskell.org/onlinereport/decls.html#default-decls
> > > http://www.haskell.org/tutorial/numbers.html#sect10.4
> >
> > I still don't see, why it works for show but not for my_show.
>
> Says the report:
>  Ambiguities in the class Num are most common, so Haskell provides another way
> to resolve them---with a default declaration:
>
>
> default (t1 , ... , tn)
>
>
> where n>=0, and each ti must be a type for which Num ti holds. In situations
> where an ambiguous type is discovered, an ambiguous type variable, v, is
> defaultable if:
>
> v appears only in constraints of the form C v, where C is a class, and
> at least one of these classes is a numeric class, (that is, Num or a subclass
> of Num), and
> all of these classes are defined in the Prelude or a standard library (Figures
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That's the point!
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 6.2--6.3, pages -- show the numeric classes, and Figure 6.1, page , shows the
> classes defined in the Prelude.)
> Each defaultable variable is replaced by the first type in the default list
> that is an instance of all the ambiguous variable's classes. It is a static
> error if no such type is found.
>
> >
> > > On 1/12/06, Jeff.Harper at handheld.com <Jeff.Harper at handheld.com> wrote:
> >
> > [...]
> >
> > >> class (Show a) => My_show a where
> > >>    my_show :: a -> String
> >
> > If I let this be
> >
> >    class My_show a where
> >        my_show :: a -> String
> >
> > >> instance My_show Int where
> > >>    my_show a = show a ++ " :: Int"
> > >>
> > >> instance My_show Integer where
> > >>    my_show a = show a ++ " :: Integer"
> >
> > What is the difference to the builtin Show class?
>
> It's not declared in the prelude or standard libraries.
> >
> > Christian
>
> Now the question is, could that restriction be lifted, i.e., would it be
> possible/worthwhile to let defaulting also take place if user defined classes
> are involved?

So long as we're going to have a defaulting mechanism, it seems a bit
odd to restrict it to Num, and to classes in the Prelude. It would be
neat if this could be somewhat generalised, so that, say, the Haskell
98 defaulting behaviour could be completely specified by declarations
in the Prelude, but it's a good question as to exactly how it should
be generalised at all.

It seems a bit tricky to come up with a way to specify the defaulting
behaviour which is both general enough to express the current
behaviour, and which doesn't result in conflicts in the orders in
which default types are tried.

The 'obvious' thing is to have a specification somewhat like:
default C (t1,...,tn)
where C is the name of a single parameter typeclass (or a
multiparameter one, with all but one of the type variables applied;
there ought to be a way to generalise to multi-parameter typeclasses
if we can sort out the problems here)

The problem comes when you have a type variable which is ambiguous,
and to which multiple defaulting specifications apply. In which order
do we try the defaults? We almost certainly wouldn't want it to
depend, for example, on the order in which the class constraints in a
type declaration were specified.

We could pick the defaulting mechanism based on order of occurrence to
some extent, but even this seems a little ugly. Also, how do these
defaults interact with modules? If we want the system to be nice and
general, it would be nice to have the behaviour with respect to Num
specified in the Prelude and merely exported, but this potentially
opens up another can of worms with regard to exporting defaults. If we
always export them, it's unclear what happens with cyclic module
dependency graphs. Perhaps there should be some provision to allow for
writing something like "default C" in the module export/import lists.

 - Cale