Proposal: Improving the IsString String instance

Dag Odenhall dag.odenhall at
Sat Aug 24 22:59:40 CEST 2013

+1 from me; I think this is why I have let s = id :: String -> String in my
~/.ghci and I agree the usefulness of being able to add other IsString
[a]instances is debatable and dubious, and the benefits from improved
defaulting of far greater value here.

On Sat, Aug 24, 2013 at 7:52 PM, Edward Kmett <ekmett at> wrote:

> 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
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list