Have you tested this? If GHC sees two overlapping instances
instance ... => IsString [a]
instance IsString [Char]
it’ll refrain from using the former until it knows that the latter can’t match.
So the “extended defaulting rules” may actually be needed.
I’m not against beefing up the extended default rules if someone wants to write a specification. It wouldn’t be hard to do.
Simon
From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Edward Kmett
Sent: 18 May 2015 02:37
To: Dan Doel
Cc: Haskell Libraries
Subject: Re: IsString [Char] instance
+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 mailto:dan.doel@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@haskell.orgmailto:Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
