String != [Char]

[Nate Soares]

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.

On Fri, Mar 23, 2012 at 1:03 PM, Thomas Schilling
<nominolo at googlemail.com>wrote:

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