On 30/11/2006, at 5:08 AM, Malcolm Wallace wrote:
Bernie Pope <[EMAIL PROTECTED]> 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.
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
