Proposal: Improving the IsString String instance

[Dag Odenhall]

+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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130824/a489ac47/attachment.htm>