Proposal: Improving the IsString String instance

[Edward Kmett]

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