IsString [Char] instance

[Michael Snoyman]

I'm +1 as well. I have a hard time thinking of a list of something besides
`Char`s for which we'd want an `IsString` instance to work for.

On Mon, May 18, 2015 at 4:36 AM Edward Kmett <ekmett at gmail.com> wrote:

> +1 from me. Let's resolve to do something about the situation before 7.12
> ships.
>
> I'd definitely prefer some kind of smarter defaulting, because that'd also
> potentially address the length "foo" overloaded string problem that got
> worse with the Foldable/Traversable Proposal, but even just the
>
> instance (a ~ Char) => IsString [a]
>
> solution goes a long way and has the benefit that it could be implemented
> today without having to figure out and test complex defaulting rules.
>
> -Edward
>
> On Mon, May 18, 2015 at 10:08 AM, Dan Doel <dan.doel at gmail.com> wrote:
>
>> Greetings,
>>
>> Today, someone came into #haskell and asked why they couldn't type the
>> equivalent of:
>>
>>     > "hi" ++ "bye"
>>
>> into GHCi with OverloadedStrings enabled. The answer is that it's
>> ambiguous, because (++) only determines the strings to be [a], and not
>> [Char].
>>
>> I noticed that this could actually be solved by making the instance:
>>
>>     instance (a ~ Char) => IsString [a] where ...
>>
>> Which causes [Char] to be inferred as soon as [a] is. I then searched my
>> libraries mail and noticed that we'd discussed this two years ago. The
>> proposal for this instance change was rejected based on
>> ExtendedDefaultRules being beefed up to solve this case. But then no one
>> actually implemented the better defaulting.
>>
>> So, I'm proposing that the issue be fixed for real. I'm not terribly
>> concerned with how it gets fixed, but there's not a great reason for this
>> to not behave better than it currently does. If someone steps up and makes
>> defaulting better, than that's great. But if not, then the libraries
>> committee can fix this very easily for GHC 7.12, and I think it's better to
>> do so than to wait if there are no signs that the alternative is going to
>> happen.
>>
>> I don't think we need to nail down which of the two solutions we're going
>> to choose right now, but it'd be good to resolve that we're going to fix
>> it, one way or another, by some well defined date.
>>
>> Here's a link to the previous discussion:
>>
>>   http://comments.gmane.org/gmane.comp.lang.haskell.libraries/20088
>>
>> Discussion period: 2 weeks
>>
>> -- Dan
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150518/a16a4b51/attachment.html>