Note that this might be a good time to consider re-factoring the list operations, for example, making ++ operate on monoids instead of just lists. I think the 'naming issue' that you mention highlights the need for better use of type classes in the prelude.<br>
<br><div class="gmail_quote">On Fri, Mar 23, 2012 at 1:03 PM, Thomas Schilling <span dir="ltr"><<a href="mailto:nominolo@googlemail.com">nominolo@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OK, so I think we should separate the parts of the proposal a bit.<br>
<br>
- Remove type String = [Char]<br>
<br>
- Make String an abstract type (it could be named Text to encourage<br>
users to think about whether they are operating on a representation<br>
of text or on a sequence of bytes).<br>
<br>
- Specify operations on such an abstract String/Text type.<br>
Personally, I think the standard shouldn't specify too many operations<br>
over such a type to not limit implementors' freedom too much.<br>
<br>
- Integrate the rest of the standard library with this new abstract<br>
type. This, I think, is actually the hardest part.<br>
<br>
I think most here agree that the main advantage of the current<br>
definition is only pedagogical. Even then Strings are often built in<br>
a very inefficient way by using ++ instead of ShowS + function<br>
composition (which actually is a builder on its own). I don't really<br>
think that having an abstract type is such a big problem for teaching.<br>
You can do string processing by doing (pack . myfunction . unpack)<br>
which is fine for this purpose. Once students are comfortable with<br>
using higher-order functions, you can tell them to use the more<br>
optimised Text-specific combinators. Builders are also a very nice<br>
application of monoids.<br>
<br>
The larger problem for the Prelude would be that you can no longer use<br>
the list functions on String/Text. This mainly leads to an issue with<br>
naming things (e.g., length for lists and length for strings).<br>
Similarly, file functions like readFile probably shouldn't return Text<br>
but ByteStrings. But that would mean making ByteString part of the<br>
Prelude as well. So I'm not too sure on these particular issues.<br>
<div class="HOEnZb"><div class="h5"><br>
On 23 March 2012 19:30, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br>
> Like I said, my objection to including Text is a lot less strong than my<br>
> feelings on any notion of deprecating String.<br>
><br>
> However, I still see a potentially huge downside from an pedagogical<br>
> perspective to pushing Text, especially into a place where it will be front<br>
> and center to new users. String lets the user learn about induction, and<br>
> encourages a "Haskelly" programming style, where you aren't mucking about<br>
> with indices and Builders everywhere, which is frankly very difficult to use<br>
> when building Text. If you cons or append to build up a Text fragment,<br>
> frankly you're doing it wrong.<br>
><br>
> The pedagogical concern is quite real, remember many introductory lanuage<br>
> classes have time to present Haskell and the list data type and not much<br>
> else. Showing parsing through pattern matching on strings makes a very<br>
> powerful tool, its harder to show that with Text.<br>
><br>
> But even when taking apart Text, the choice of UTF16 internally makes it<br>
> pretty much a worst case for many string manipulation purposes. (e.g.<br>
> slicing has to spend linear time scanning the string) due to the existence<br>
> of codepoints outside of plane 0.<br>
><br>
> The major benefits of Text come from FFI opportunities, but even there if<br>
> you dig into its internals it has to copy out of the array to talk to<br>
> foreign functions because it lives in unpinned memory unlike ByteString.<br>
><br>
> The workarounds for these limitations all require access to the internals,<br>
> so a Text proposed in an implementation-agnostic manner is less than useful,<br>
> and one supplied with a rigid set of implementation choices seems to<br>
> fossilize the current design.<br>
><br>
> All of these things make me lean towards a position that it is premature to<br>
> push Text as the one true text representation.<br>
><br>
> That I am very sympathetic to the position that the standard should ensure<br>
> that there are Text equivalents for all of the exposed string operations,<br>
> like read, show, etc, and the various IO primitives, so that a user who is<br>
> savvy to all of these concerns has everything he needs to make his code<br>
> perform well.<br>
><br>
> Sent from my iPad<br>
><br>
> On Mar 23, 2012, at 1:32 PM, Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br>
><br>
> On Fri, Mar 23, 2012 at 13:05, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br>
>><br>
>> Isn't it enough that it is part of the platform?<br>
><br>
><br>
> As long as the entire Prelude and large chunks of the bootlibs are based<br>
> around String, String will be preferred. String as a boxed singly-linked<br>
> list type is therefore a major problem.<br>
><br>
> --<br>
> brandon s allbery <a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a><br>
> wandering unix systems administrator (available) <a href="tel:%28412%29%20475-9364" value="+14124759364">(412) 475-9364</a> vm/sms<br>
><br>
><br>
</div></div><div class="im HOEnZb">> _______________________________________________<br>
> Haskell-prime mailing list<br>
> <a href="mailto:Haskell-prime@haskell.org">Haskell-prime@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-prime" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-prime</a><br>
><br>
<br>
<br>
<br>
</div><div class="im HOEnZb">--<br>
Push the envelope. Watch it bend.<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Haskell-prime mailing list<br>
<a href="mailto:Haskell-prime@haskell.org">Haskell-prime@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-prime" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-prime</a><br>
</div></div></blockquote></div><br>