IsString [Char] instance

Dan Doel dan.doel at gmail.com
Wed Aug 12 16:14:33 UTC 2015


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

On Sun, May 17, 2015 at 8:08 PM, 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


More information about the Libraries mailing list