Re: Proposal: Improving the IsString String instance

+1 OverloadedStrings is meant as a convenience, this ensures it better satisfies that goal. On 24 August 2013 20:20, Michael Snoyman wrote:

On Sat, Aug 24, 2013 at 8:52 PM, Edward Kmett 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@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@haskell.org http://www.haskell.org/mailman/listinfo/libraries