Re: defaults

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

Bernie Pope 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.