So I've been thinking about something, and I'm curious whether anyone (in particular, people involved with GHC) think this is a worthwhile idea. I'd like to implement an extension to GHC to offer a different behavior for literals with polymorphic types. The current behavior is something like: 1. Give the literal a polymorphic type, like (Integral a => a) 2. Type check the whole program, possibly giving the term a more constrained type. 3. If the type is still ambiguous, apply defaulting rules. I'd like to add the option to do this instead. 1. Take the polymorphic type, and immediately apply defaulting rules to get a monomorphic type. 2. Type check the program with the monomorphic type. Mostly, this would reduce the set of valid programs, since the type is chosen before considering whether it meets all the relevant constraints. So what's the purpose? To simplify type errors for programmers who don't understand type classes. What I have in mind is domain-specific dialects of Haskell that replace the Prelude and are aimed at less technical audiences - in my case, children around 10 to 13 years old; but I think the ideas apply elsewhere, too. Type classes are (debatably) the one feature of Haskell that tends to be tricky for non-technical audiences, and yet pops up in very simple programs (and more importantly, their error messages) even when the programmer wasn't aware of it's existence, because of its role in overloaded literals. In some cases, I think it's a good trade to remove overloaded literals, in exchange for simpler error messages. This leaves new programmers learning a very small, simple language, and not staring so much at cryptic error messages. At the same time, it's not really changing the language, except for the need to explicitly use type classes (via conversion functions like fromInteger) rather than get them thrown in implicitly. With GHC's extended defaulting rules that apply for OverloadedStrings, this could also be used to treat all string literals as Text, too, which might make some people happy, too. Of course, the disadvantage is that for numeric types, you would lose the convenience of overloaded operators, since this is only a sensible thing to do if you're replacing the Prelude with one that doesn't use type classes. But in at least my intended use, I prefer to have a single Number type anyway (and a single Text type that's not sometimes called [Char]). In the past, explaining these things has eaten up far too much time that I'd rather have spent on more general skills and creative activities.