I've been chewing on this one for a long time, and finally decided to post it after being bitten by it *again*. Right now we have a very fragile instance in base for instance IsString String where fromString = id This is fragile because once you turn on OverloadedStrings length "hello" won't work any more, because all it knows is that it has a [a] such that it needs an IsString [a] instance, but it can't use defaulting to select the [Char] instance we've defined, and so you have to burden it with a type annotation.
:set -XOverloadedStrings length "hello"
<interactive>:3:8: No instance for (Data.String.IsString [a0]) arising from the literal `"hello"' The type variable `a0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there is a potential instance available: instance Data.String.IsString [Char] -- Defined in `Data.String' Possible fix: add an instance declaration for (Data.String.IsString [a0]) In the first argument of `length', namely `"hello"' In the expression: length "hello" In an equation for `it': it = length "hello" I would like to replace this instance with instance a ~ Char => IsString [a] where fromString = id This will make OverloadedStrings work much better with the list-specific combinators, reducing the number of type annotations required by users who hack on, say, web-apps in Haskell where both OverloadedStrings is a common extension and, frankly, the users are often the least equipped to deal with and understand the issue. The cost of this instance is that someone else can't come along and make an instance of IsString for another 'character-like' type and get the String-like behavior with magic list interoperability without some kind of wrapper. However, I've yet to see any such instances, and I'd likely look down my nose at such an instance in the first place. ;) The current pain is real and the space of instances affected seems both largely theoretical and a bad idea to begin with. The instance is already guarded from use by NHC by an #ifdef, which limits objections on portability grounds. Discussion Period: 2 Weeks