<div dir="ltr">Mario, thanks for that great writeup. <br><br>The switch can only happen if there's a way to make the old code somehow transparently work the same or better in the new setup. <br><br>Maybe some GHC magic could bring the string operations to Prim Ops and transparently switch the underlying representation to Text from [Char]. Basically, Text would have to become a built in primitive, not a library.<br><br clear="all"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div>Michał <br></div></div></div></div>
<br><div class="gmail_quote">On Fri, May 22, 2015 at 10:29 AM, Mario Blažević <span dir="ltr"><<a href="mailto:mblazevic@stilo.com" target="_blank">mblazevic@stilo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15-05-18 06:44 PM, Andrew Gibiansky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey all,<br>
<br>
In the earlier haskell-cafe discussion of IsString, someone mentioned<br>
that it would be nice to abandon [Char] as the blessed string type in<br>
Haskell. I've thought about this on and off for a while now, and think<br>
that the fact that [Char] is the default string type is a really big<br>
issue (for example, it gives beginners the idea that Haskell is<br>
incredibly slow, because everything that involves string processing is<br>
using linked lists).<br>
<br>
I am not proposing anything, but am curious as to what already has been<br>
discussed:<br>
<br>
1. Has the possibility of migrating away from [Char] been investigated<br>
before?<br>
</blockquote>
<br></span>
No, not seriously as far as I'm aware. That ship has sailed a long time ago. Still, as I have actually thought about that, I'll give you an outline of a possible process.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. What gains could we see in ease of use, performance, etc, if [Char]<br>
was deprecated?<br>
</blockquote>
<br></span>
They could be very significant for any code that took advantage of the new type, but the existing code would not benefit that much. But then, any new Haskell code can already use Text where performance matters.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. What could replace [Char], while retaining the same ease of use for<br>
writing string manipulation functions (pattern matching, etc)?<br>
</blockquote>
<br></span>
You would not have the same ease of use exactly. The options would lie between two extremes. At one end, you can have a completely opaque String type with fromChars/toChars operations and nothing else. At the other end, you'd implement all operations useful on strings so there would never be any need to convert between String and [Char].<br>
<br>
The first extreme would be mostly useless from the performance point of view, but with some GHC magic perhaps it could be made a viable upgrade path. The compiler would have to automatically insert the implicit fromChars/toChars conversion whenever necessary, and I expect that some of the existing Haskell code would still be broken.<br>
<br>
Once you have an opaque String type, you can think about improving the performance. A more efficient instance of Monoid String would be a good start, especially since it wouldn't break backward compatibility. Unfortunately that is the only [Char] instance in wide use that can be easily optimized. Perhaps Foldable could be made to work with even more compiler magic, but I doubt it would be worth the effort.<br>
<br>
If you add more operations on String that don't require<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. Is there any sort of migration path that would make this change<br>
feasible in mainline Haskell in the medium term (2-5 years)?<br>
</blockquote>
<br></span>
Suppose GHC 7.12 were to bring Text into the core libraries, change Prelude to declare type String = Text, and sprinkle some magic compiler dust to make the explicit Text <-> Char conversions unnecessary.<br>
<br>
The existing Haskell code would almost certainly perform worse overall. The only improved operations would be mappend on String, and possibly the string literal instantiation.<br>
<br>
I don't think there's any chance to get this kind of change proposal accepted today. You'd have to make the pain worth the gain.<br>
The only viable path is to ensure beforehand that the change improves more than just the mappend operation.<br>
<br>
In other words, you'd have to get today's String to instantiate more classes in common with tomorrow's String, and you'd have to get the everyday Haskell code to use those classes instead of list manipulations.<br>
<br>
The first tentative step towards the String type change would then be either the mono-traversable or my own monoid-subclasses package. They both define new type classes that are instantiated by both [Char] and Text. The main difference is that the former builds upon the Foldable foundation, the latter upon Monoid. They are both far from being a complete replacement for list manipulations. But any new code that used their operations would see a big improvement from the String type change.<br>
<br>
Here, then, is the five-year plan you're asking for:<br>
<br>
Year one: Agree on the ideal set of type classes to bridge the gap between [Char] and Text.<br>
<br>
Year two: Bring the new type classes into the Prelude. Have all relevant types instantiate them. Everybody's updating their code in delight to use the new class methods.<br>
<br>
Year three: GHC issues warnings about using List-specific [], ++, null, take, drop, span, drop, etc, on String. Everybody's furiously updating their code.<br>
<br>
Year four: Add Text to the core libraries. The GHC magic to make the Text <-> [Char] convertions implicit is implemented and ready for testing but requires a pragma.<br>
<br>
Year five: Update Haskell language report. Flip the switch.<br>
<br>
So there. How feasible does that sound?<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div></div>