
I think we should ditch the notion that it's valid to round-trip from
Word32 to Char and back. Char should *only* take on valid codepoints
(although not only assigned ones). This will break some code
(particularly some weird stuff with file names, IIRC), but I think
that code is broken already. I don't, however, think that will fully
address Yitzchak's concerns.
On Mon, May 18, 2015 at 12:22 PM, Dan Doel
On Mon, May 18, 2015 at 10:57 AM, Yitzchak Gale
wrote: Michael Snoyman wrote:
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.
I have an easy time. The `Data.Char` module is always woefully behind the Unicode standard, and there are always Unicode features that are implemented differently than what some people might want.
A case in point is toUpper and toLower. Those were fixed in Data.Text, but are still broken in Data.Char.
For me, so far this has not been important enough for me to need to implement my own Char type, or a newtype wrapper with improvements. But it is certainly conceivable that others might need this.
Whether or not you like those examples - it is really the wrong approach to outlaw IsString [a] instance forever more for any a except Char.
I'm a little skeptical that someone would be concerned about proper Unicode support and still want [Codepoint]---with no abstraction barrier---to be the string type. I think it'd even be good if we could ditch [Char] as the blessed string type in Haskell altogether. But that's a much more involved process.
Yes, this is a serious problem that should be solved. But are we really giving up on doing it the right way and fixing defaulting rules? Simon wrote that it wouldn't be hard.
It doesn't really matter how hard it is unless someone actually does it.
I'm not exactly sure what people want out of beefed up defaulting, and what is feasible, either. Fixing 'show ("fizz" ++ "buzz")' is easy. If it also has to fix 'length "hello"', that may be more tricky, although it's something that the instance solution isn't really capable of fixing. So it's best not to get hung up on that.
I propose: Set a reasonable time limit for someone to step up and provide a suggested fix to the defaulting rules. If that doesn't happen, then bite the bullet and do it using the type equality
What is a reasonable time limit? It's been two years already. 7.12 is probably between 1/2 and 1 more. Do we really need more than that?
-- Dan
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries