Proposal: Improving the IsString String instance

[Christopher Done]

+1

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


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

>
>
>
> On Sat, Aug 24, 2013 at 8:52 PM, Edward Kmett <ekmett at gmail.com> 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 haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
> 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 haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130824/9b97f59a/attachment.htm>