[Haskell-cafe] Abandoning String = [Char]?

Fri May 22 21:57:39 UTC 2015

one direction that this thread has *COMPLETELY* overlooked is the following:

could we use pattern synonyms or something along those lines to make the
migration to Text or the like more seemless?

On Fri, May 22, 2015 at 1:55 PM, Mike Meyer <mwm at mired.org> wrote:

> Having just finished converting my Haskell shell-scripting tool from
> Strjng to Text/ByteString, might I suggest that such a change would create
> fewer problems after a Prelude rework to something like ClassyPrelude?
> Using ClassyPrelude meant that a lot of the code that worked with String
> worked just fine with Text and ByteString. I had more fixes due to having
> used partial function than with no longer having List's of chars.
>
> On Fri, May 22, 2015 at 12:37 PM, Andrew Gibiansky <
> andrew.gibiansky at gmail.com> wrote:
>
>> Mario,
>>
>> Thank you for that detailed write-up. That's exactly the sort of thing I
>> was looking for.
>>
>> I imagine a path like the one you describe is possible, but very, very
>> difficult, and likely the effort could be better spent elsewhere.
>>
>> I imagine an alternate route (that would have immediate gains in the near
>> future, and wouldn't be a long-term transition plan) would be to have a
>> `text-base` package, which exports everything `base` does, exporting `Text`
>> instead of `String`. Then base packages off that instead of `base`, thus
>> ensuring you do not rely on []-manipulation for `String` (you should still
>> have full compatibility with normal `base`).
>>
>> Anyway, hard choices all around, for no 100% clear gain, so I personally
>> do not envision this happening any time soon. Oh well...
>>
>> -- Andrew
>>
>> On Fri, May 22, 2015 at 6:07 PM, Michal Antkiewicz <
>> mantkiew at gsd.uwaterloo.ca> wrote:
>>
>>> Mario, thanks for that great writeup.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Michał
>>>
>>> On Fri, May 22, 2015 at 10:29 AM, Mario Blažević <mblazevic at stilo.com>
>>> wrote:
>>>
>>>> On 15-05-18 06:44 PM, Andrew Gibiansky wrote:
>>>>
>>>>> Hey all,
>>>>>
>>>>> In the earlier haskell-cafe discussion of IsString, someone mentioned
>>>>> that it would be nice to abandon [Char] as the blessed string type in
>>>>> Haskell. I've thought about this on and off for a while now, and think
>>>>> that the fact that [Char] is the default string type is a really big
>>>>> issue (for example, it gives beginners the idea that Haskell is
>>>>> incredibly slow, because everything that involves string processing is
>>>>> using linked lists).
>>>>>
>>>>> I am not proposing anything, but am curious as to what already has been
>>>>> discussed:
>>>>>
>>>>> 1. Has the possibility of migrating away from [Char] been investigated
>>>>> before?
>>>>>
>>>>
>>>>         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.
>>>>
>>>>
>>>>  2. What gains could we see in ease of use, performance, etc, if [Char]
>>>>> was deprecated?
>>>>>
>>>>
>>>>         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.
>>>>
>>>>
>>>>  3. What could replace [Char], while retaining the same ease of use for
>>>>> writing string manipulation functions (pattern matching, etc)?
>>>>>
>>>>
>>>>         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].
>>>>
>>>>         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.
>>>>
>>>>         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.
>>>>
>>>>         If you add more operations on String that don't require
>>>>
>>>>
>>>>  4. Is there any sort of migration path that would make this change
>>>>> feasible in mainline Haskell in the medium term (2-5 years)?
>>>>>
>>>>
>>>>         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.
>>>>
>>>>         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.
>>>>
>>>>         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.
>>>> The only viable path is to ensure beforehand that the change improves
>>>> more than just the mappend operation.
>>>>
>>>>         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.
>>>>
>>>>         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.
>>>>
>>>>         Here, then, is the five-year plan you're asking for:
>>>>
>>>> Year one: Agree on the ideal set of type classes to bridge the gap
>>>> between [Char] and Text.
>>>>
>>>> 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.
>>>>
>>>> Year three: GHC issues warnings about using List-specific [], ++, null,
>>>> take, drop, span, drop, etc, on String. Everybody's furiously updating
>>>> their code.
>>>>
>>>> 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.
>>>>
>>>> Year five: Update Haskell language report. Flip the switch.
>>>>
>>>> So there. How feasible does that sound?
>>>>
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150522/a1153513/attachment-0001.html>