Proposal: Improving the IsString String instance

Christopher Done chrisdone at
Sat Aug 24 20:27:26 CEST 2013


OverloadedStrings is meant as a convenience, this ensures it better
satisfies that goal.

On 24 August 2013 20:20, Michael Snoyman <michael at> wrote:

> On Sat, Aug 24, 2013 at 8: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
> This seems like a good overall change to me. I understand that we're
> giving up some flexibility, but the user-facing simplicity is probably
> worth it. +1 from here.
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list