Proposal: Improving the IsString String instance
chrisdone at gmail.com
Sat Aug 24 20:27:26 CEST 2013
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"
>> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries