+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@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries