Simon Peyton-Jones wrote:

remember that defaulting does not happen class-by-class at the moment.

Yes, and this is exactly the point of the proposal (#2). It makes sense (to me at least) to change the rules so that defaulting happens per-class. At the moment, it _can_ occur for any class, provided only that the type is _also_ constrained to be an instance of Num. It is a very strange rule, and one that I guess very few people understand fully, yet I hope to show that one can subsume it entirely by introducing a different but more general rule, that is easier to understand.

If you have (Eq a, Fractional a) where 'a' is unconstrained, the current rules pick the first type T in the defaulting list that satisfies all the constraints (Eq T, Fractional T). I don't know what would that would mean if Eq had a different defaulting list than Fractional, as you propose.

Well, for one thing I don't like the idea of a "list" of potential defaults. My suggestion is that there should be a single default type per class. If more than one class is involved, then either their defaults should agree, or only one of them in fact declares a default. I claim that this would be sufficient for every extant use case. But I would quite like to have some evidence to back up this claim! If anyone actually uses explicit defaults in their programs, I would be interested in seeing some real data on this. Feel free to submit such example decls to my email address. I suspect that almost no-one uses defaults except for the original motivating case of literal numbers. If so, then even quite a big change in this area would hurt very few people, provided it was backward compatible with the literal number thing.

Another issue that Haskell' needs to address is what defaulting means when you have multi-parameter type classes.

Yes, I was going to mention that myself on the wiki, but it slipped my mind again. So here is one idea. If you have a single default type per class in the SPTC scenario, then you would have a single default _relation_ of types in the MPTC case. The default decl could be made to look rather like an instance decl: default Num Integer default Fractional Double class Dual d c where ... default Dual Binary [Bool] except, unlike instances, you are permitted only one of them. Regards, Malcolm

"Josef Svenningsson" wrote:

...

If anyone actually uses explicit defaults in their programs, I would be interested in seeing some real data on this.

Ah, another fine opportunity to use Google Code Search. And even more so now that it supports Haskell code!

An excellent suggestion, thank you! Several things strike me about this data: * Very few projects use defaulting (only 30 results show up, and I am the author of 6 of those). * I had forgotten about the important need to turn _off_ defaulting (now added to my proposal). * Extant uses fall into 3 main categories: . turning off defaults because Hat and Buddha cannot handle them well . changing default(Integer) to default(Int) for compatibility with pre-Haskell-1.4 behaviour, or for performance reasons (in Hugs) . introducing a new numeric type (e.g. GLfloat, Number) Of course, what the extant data cannot show is how authors would _like_ to have used defaulting, but were prevented from doing so by the language spec. Well, maybe the Hat and Buddha examples hint at it. I can also imagine that it would be useful to have per-class defaults for user-defined classes in something like QuickCheck or SmallCheck. It is tedious to need to add to your property specification some exact type signature to constrain the polymorphic values such that the system can generate some of them. It would be so much easier to be able to say default Arbitrary Int or default Serial Bool and then the system could generate appropriate test cases without the extra human work of adding lots of signatures. Regards, Malcolm P.S. updated proposal here: http://hackage.haskell.org/trac/haskell-prime/wiki/Defaulting

Simon Peyton-Jones writes:

| My suggestion is that there should be a single default type | per class.

Ah, I missed that.

I suppose, because the proposed new rule is so simple and short, it is rather easy to miss its implications, especially if you are used to thinking in terms of the existing more complicated rule.

Suppose I have default Eq Integer default Fractional Float and I have (Eq a, Fractional a). Does 'a' resolve to Integer or to Float? Perhaps a few examples on the proposal page would be useful for readers?

The proposed rule is that defaulting applies *after* simplification of the context. So, although you initially infer (Eq a, Fractional a) => a but after simplification, this becomes (Fractional a) => a so there is a single class to be defaulted, and Float is chosen. Here are some more examples. default Ord Integer default Fractional Float (Ord a, Fractional a) => a --> static error, because Ord is not a superclass of Fractional, so the context does not simplify, and the default types disagree. default Bounded Int default Ord Int (Ord a, Bounded a) => a --> default is Int, because even though the context does not simplify, the classes involved do agree on which default to choose. default Bounded Int default Ord Int (Ord a, Bounded a, Show a) => a --> default is Int, same as above, except for the extra constraint Show a. There is no default declared for Show, so the remaining context is used to make the choice. (Show a, Read a) => a --> static error, because there are no defaults declared for any of the classes involved. Regards, Malcolm

Simon Peyton-Jones wrote:

I think this thread is discussing your proposal 2, ignoring 1.

Indeed. Proposal 1 was from John Meacham, and I have edited it further to show how even simple lists lead to non-confluence. I had hoped that by simplifying from lists to unique types (in proposal 2), that we could regain confluence. But your example below shows that I have not yet fully achieved that goal.

Suppose you had (Eq a, Foo a b, Num b) If I start with (Eq a) I might choose Integer. But if I start with Num b, I might choose default b=Float. Suppose I have instance Fractional a => Foo a Float Now I simplify (Foo a Float) to get Fractional a, and now I should choose a=Float.

Ah, but here you have an MPTC: Foo a b. Currently, Haskell'98 has no story at all for how defaulting would work over MPTCs. According to the Report, the type variable 'a' is not defaultable, because it is not directly constrained by a numeric class. OK, so if we change the example slightly to satisfy that condition, does Haskell'98 say anything then? ( Fractional a, Foo a b, Num b ) Of course, it still falls foul of the rule that a variable 'v' can only be constrained in the form (C v), but setting that aside also... So if I have instances: instance Foo Float Integer instance Foo Double Int and default (Int,Integer,Float,Double) then which are the "first" types for 'a' and 'b' from the list to satisfy all the constraints? The possible choices are incomparable with each other for "firstiness". My proposal for defaulting MPTCs does not fix this. I had failed to consider the case that defaulting one of the variables may cause an instance to become available, which might immediately constrain the other variable(s) further. The order in which you choose to default variables might therefore give you different constraints on the other variables. One solution might be simply to disallow defaulting over MPTC. (I can't immediately think of any useful applications.) Another solution might be to say that defaulting will only occur *if* it is confluent, i.e. the compiler should try all possible orderings in which to default variables, and if they do not come up with the same answer, then reject the program. Regards, Malcolm

Simon Marlow wrote:

Is your proposal supposed to be backwards compatible with Haskell 98 for programs that don't have default declarations?

Yes, it is supposed to be backwards compatible.

If so, then I offer a counter example: toRational pi will default pi to Double in Haskell 98, but will be an error under your proposal, because the two constraints (Real and Floating) disagree on the default.

Well spotted. So there are some expressions that are defaulted in H'98 but would not pass type-checking with my proposal. (1) Are examples like this common? I am guessing not. You mention Enum/Fractional combinations, but arguably Float and Double do not belong in Enum anyway. (2) The new rule is conservative - it does not silently change the semantics, but it does reject more programs. Such programs are easily fixed by adding a type signature. If these two points are valid, then I think the slight loss of backward compatibility is acceptable? Regards, Malcolm

Simon Marlow wrote:

...

...

If so, then I offer a counter example: toRational pi

If these two points are valid, then I think the slight loss of backward compatibility is acceptable?

I spotted the problem because it looks (to me) like the current Haskell 98 rule is designed specifically to handle cases like this.

I agree that having to write toRational (pi::Double) is somewhat ugly.

Would you mind updating the wiki page? I don't think it's too clear on the need for constraint simplification before applying your defaulting rules either.

I have added your counter example to the wiki. But I'm not sure how to make the need for constraint simplification clearer. 3 out of the 7 sentences in the proposal describe it, and 3 out of the 5 examples mention its role. What do you think is missing? Regards, Malcolm

On 28/11/2006, at 11:28 AM, Ian Lynagh wrote:

On Mon, Nov 20, 2006 at 12:05:46PM +0000, Malcolm Wallace wrote:

...

Prompted by recent discussion on the Hat mailing list about the problems of type-defaulting, I have added two new proposals for this issue to the Haskell-prime wiki at:

http://hackage.haskell.org/trac/haskell-prime/wiki/Defaulting

I don't see a proposal to remove defaulting defaulting altogether on that page - has that been discussed already?

Am I the only one who puts an explicit type signature in whenever my compiler warns me that it is having to do some defaulting? And probably 99% of those would be unnecessary if (^)'s second argument was an Int, with a genericPower (or whatever) function providing the current type signature (analogous to, for example, (!!) and genericIndex).

Defaulting is one wart I would be glad to be rid of.

I would also be happy if it was removed. My main reasons are: 1) It makes teaching Haskell more difficult, because it is a special case mechanism. I would prefer consistency here. 2) It makes source-to-source program transformations more difficult, as found in Hat etc. 3) I have found it easy to avoid with the addition of type annotations. I don't write a lot of numeric code, so the benefits I personally get from defaulting have so far been minimal, and that has coloured my view. Others may find it more useful. Cheers, Bernie.

On Wed, Nov 29, 2006 at 06:08:14PM +0000, Malcolm Wallace wrote:

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.

Following a suggestion of Ralf Hinze, GHCi and Hugs already perform more defaulting on interpreted expressions than on definitions in modules (where they follow Haskell 98). Thus "reverse []" just works, instead of provoking ERROR: Cannot find "show" function for: *** expression : reverse [] *** of type : [a] See http://www.haskell.org/ghc/docs/latest/html/users_guide/ch03s04.html#extende... So if defaulting were removed from the language it could still be done at the interpreter prompt.

On Thu, 2006-11-30 at 12:21 +1100, Bernie Pope wrote:

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.

If it's on a per-class basis then it would be reasonable to allow the default to be exported, no? Then you just have to argue about if the default Prelude should export defaults for the Num and other standard classes. For my GUI OOP inheritance hierarchy use-case I'd certainly want to export the default. It'd be pretty useless otherwise (I don't mean in general, just for this use-case). Duncan

On 30/11/2006, at 3:36 PM, Ashley Yakeley wrote:

Malcolm Wallace wrote:

...

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.

I propose we abandon "teaching" arguments for design choices entirely. There are two reasons for this. Firstly, they don't apply to the majority of Haskell users, and secondly, they almost always misapprehend the language-learning process.

To give you a vague example, when I was learning ML, what appealed to me was the sense of cleanliness and purity about the language. Any apparent weirdness was fine, as long as I could discover the elegant reason behind it. This right up until finding out about references, which bothered me so much that I dropped it and learnt Haskell instead.

That something might confuse the beginning user should count for nothing if it does not annoy the more experienced user.

Whilst I agree with some of your sentiment, I think that this argument is too extreme. On a general level, for a language with a relatively small community, Haskell has been rather successful as a vehicle for education. I don't think we should underestimate the impact that this exposure has had on the language. Teachers of Haskell, and students of Haskell, are important members of the community, and their opinions are not irrelevent. Having said that, I agree that we should be careful with arguments based on the grounds of ease of teaching, especially so when we don't have good data to back them up. In many cases, I think that we should fix the compilers first, before we try to fix the language, in particular the error messages generated by them. You can't please all of the people all of the time, so there will naturally be situations where different user groups have competing interests. If a design decision would impinge on both the experienced users and the beginners, then, of course, a value judgement has to be made. I see no reason to rule out the needs of teaching altogether, especially in cases where there is no real conflict with other user groups. Cheers, Bernie.

Hello, On 11/30/06, Philippa Cowderoy wrote:

On Wed, 29 Nov 2006, Ashley Yakeley wrote:

...

That something might confuse the beginning user should count for nothing if it does not annoy the more experienced user.

This experienced user regularly uses a haskell interpreter for a desk calculator, not to mention for producing readable budgets that show all the working. Removing defaulting would make that extremely tedious.

I do what you suggest all the time (I mean using Hugs as a calculator) and I agree that it would be annoying without some sort of defaulting. However, I am not sure that this particular use justifies the addition of defaulting to the _language_. For example, it is possible that defaulting is implemented as a switch to the command-line interpreter. By the way, I agree with Ashley that the "it is hard to teach" argument is over-used. -Iavor

Hello Iavor, Thursday, November 30, 2006, 8:41:43 PM, you wrote:

However, I am not sure that this particular use justifies the addition of defaulting to the _language_. For example, it is possible that defaulting is implemented as a switch to the command-line interpreter.

how about using Haskell for scripting? i find it as great alternative to perl/ruby, particularly because i don't want to remember two languages, particularly because of great data processing instruments -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

defaulting can also be used for non-standard arithmetic in teaching (not something you want to let loose on students who you don't want to know about type classes, though, so be careful where you demonstrate this;-): http://www.cs.kent.ac.uk/people/staff/cr3/toolbox/haskell/R.hs Main> foldr1 (*) [1..5] (1 * (2 * (3 * (4 * 5)))) Main> foldl (*) 1 [1..5] (((((1 * 1) * 2) * 3) * 4) * 5) Main> foldr (*) 1 [1..5] (1 * (2 * (3 * (4 * (5 * 1))))) Main> map (+) [1..4] [\x->(1 + x),\x->(2 + x),\x->(3 + x),\x->(4 + x)] Main> map (1+) [1..4] [(1 + 1),(1 + 2),(1 + 3),(1 + 4)] Main> map (1+) [1..4] :: [Int] [2,3,4,5] this was written long ago, with Hugs in mind, where the defaulting applies to the interactive loop - with GHCi, you'll need to add -fglasgow-exts, and still don't get the defaulting interactively (?), so you'll need to write the type annotations: *Main> foldr (-) 0 [1..4] :: R Int (1 - (2 - (3 - (4 - 0)))) *Main> foldl (-) 0 [1..4] :: R Int ((((0 - 1) - 2) - 3) - 4) of course, this would be fine if defaults could be set in the interactive loop itself, so you don't need defaults here, and one might argue that having to give type annotations is annoying, but instructive.. personally, I use default very rarely, but that kind of reasoning has never been a good argument for excluding a feature that others like. I would agree, however, that the monomorphism restriction should go (warning only), so that defaulting cannot change my 1 :: Num a => a constants from Behaviours to Integers; with DMR gone, there may be less need for defaulting, but I would also agree that defaulting should be generalized so that its current use becomes a special case of disambiguating overloading for a whole module/program/session, without having to specialize the type-signatures everywhere in the code. and yes, teaching is important, and Haskell is not only about teaching, so teaching needs need to be addressed like the needs of any other important Haskell application area: by optional, but widely supported, domain-specific libraries/packages/flags/syntax/.. Just my (2 :: Num a => a), Claus

Malcolm Wallace wrote:

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.

I remember someone proposing a Beginner's Prelude. Such a Prelude could solve almost all the teaching problems that are regularly brought against making the language or the standard libraries more generic and orthogonal (and thus more useful for the experienced programmer, and additionally to those of us who, even as beginners, rather accept "apparent weirdness, as long as [they] could [eventually] discover the elegant reason behind it", as Ashley so nicely put it). Witness the eternal 'map' vs. 'fmap' argument: Beginner's Prelude could define map::(a->b)->[a]->[b] and /not/ import the Functor class, whereas serious users would import Control.Functor or whatever and have the more generic map from class Functor. In the particular case that's been discussed here (defaulting), the solution is to have Integer be the only integral type in the new Prelude. It has also been argued that the experienced programmer doesn't need any Prelude at all, she can import all the stuff she needs explicitly; the penalty for that would be small since any non-trivial piece of code needs to import lots of modules explicitly anyway. The logical consequence is to rename Beginner's Prelude back to just Prelude. One proposal I remember was to implicitly import the Prelude (and I'd say this should be the stripped down Beginner's version) only for modules with no 'module Main' header which I think is a nice compromise and could also be the default if you fire up ghci or hugs without arguments. Of course one can also import Prelude explicitly, if desired. Ben