Re: IsString [Char] instance

I'm fully on board with just moving ahead with this simple change for now. It'd be nice to have a better defaulting story, but I'm not sure there _is_ a perfect solution in the wings. -Edward On Wed, Aug 12, 2015 at 12:14 PM, Dan Doel wrote:

So, I rather lost track of this. It has been (significantly) more than the specified amount of time, though.

No one has stepped up to specify/implement the new extended defaulting to my knowledge. I'm not sure how much time is left before 7.12, but I would guess it'd be tight for someone to start on this now. Perhaps I'm wrong.

Anyhow, I think we should modify the instance at this point. I think it's even cool to say we can roll it back if someone decides to beef up defaulting, in which case rolling it back should cause no regressions. But it doesn't seem like defaulting is going to happen.

-- Dan

...

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

...

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

On Sun, May 17, 2015 at 8:08 PM, Dan Doel wrote: the 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.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries