IsString [Char] instance

[Edward Kmett]

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 <dan.doel at gmail.com> 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
>
> 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
> _______________________________________________
> 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/20150812/ad3dde67/attachment.html>