[Haskell-cafe] Possible extension to Haskell overloading behavior

[Chris Smith]

Oops, when I wrote this, I'd assumed it was possible to export
defaults from a module, like an alternate Prelude.  But it looks like
they only affect the current module.  So this whole thing depends on
also being able to either define defaults in an imported module, or in
options to GHC.

On Mon, Jul 8, 2013 at 12:54 PM, Chris Smith <cdsmith at gmail.com> wrote:
> 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.