bjpop at csse.unimelb.edu.au
Wed Nov 29 20:21:59 EST 2006
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
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
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
Type classes are often mysterious to the beginner, but this
seemingly inconsistent behaviour just makes them appear even more
I don't think it would hurt too much to have "1+2" rejected by the
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
they are prepared from the start, at the expense of a slightly more
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
> 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
does defaulting get exported across module boundaries? I would be
to say "no", but there may be compelling arguments for it.
More information about the Haskell-prime