defaults

[Bernie Pope]

On 30/11/2006, at 5:08 AM, Malcolm Wallace wrote:

> Bernie Pope <bjpop at csse.unimelb.edu.au> wrote:
>
>>> I don't see a proposal to remove defaulting defaulting altogether on
>>> that page - has that been discussed already?
>>>
>>> Defaulting is one wart I would be glad to be rid of.
>>
>> I would also be happy if it was removed.
>
> Me too, in some ways.  But...
>
>> 1) It makes teaching Haskell more difficult, because it is a special
>>     case mechanism. I would prefer consistency here.
>
> Unfortunately, I suspect that teaching is _the_ major use-case for
> defaulting.  Imagine, day one, lesson one, a student types
>
>     Prelude> 1+2
>
> into Hugs, and gets the response
>
>     Unresolved overloading: Num a
>
> Huh?  This is lesson one, and you already need to tell students about
> type classes and overloading, before you have even covered simple
> expressions fully?  I am certain this is the reason why defaulting was
> introduced.

Yes, numerical expressions do cause trouble from day one ---  
especially so when
the teaching staff are not Haskell experts (as is sometimes the case).
But I don't think defaulting necessarily makes the job of teaching  
any easier, and
in my opinion it just creates its own problems.

At some point, very early on, perhaps also on day one, you are going  
to tell
students about types (at least some of the base types).

So you write:

    Prelude> :t 1+2
    1+2 :: Num a => a

What the? Now you have to explain what this means _and_ you have to
explain why we were able to evaluate it as above, even though it is
ambiguous.

Type classes are often mysterious to the beginner, but this
seemingly inconsistent behaviour just makes them appear even more
magical.

I don't think it would hurt too much to have "1+2" rejected by the  
type checker
outright. You can ask for the type, discuss the ambiguity, and then
fix it with a type annotation:

    Prelude> 1+2 :: Int

Students are going to bump into this issue sooner or later, and it is  
best
they are prepared from the start, at the expense of a slightly more  
involved
discussion in the first lesson.

>
>> 2) It makes source-to-source program transformations more difficult,
>> as found in Hat etc.
>
> Sure, I'd be glad to improve that.  Removing defaults altogether would
> solve the problem for the average user.  But power users like Duncan
> would like to _extend_ defaulting to work over GUI type classes, and
> that too seems a reasonable request to me.  Does my proposal for
> revision of defaults allow that, and still make Hat-style  
> transformation
> easier?  Yes, I think so.

A compromise is to turn defaulting off "by default". This would mean
that if you want defaulting you have to ask for it. The question then  
would be:
does defaulting get exported across module boundaries? I would be  
inclined
to say "no", but there may be compelling arguments for it.

Cheers,
Bernie.