String != [Char]
nate at so8r.es
Fri Mar 23 21:21:48 CET 2012
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
> > 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
> > 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
> > 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
> > so a Text proposed in an implementation-agnostic manner is less than
> > 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
> > push Text as the one true text representation.
> > That I am very sympathetic to the position that the standard should
> > 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
> > 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>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-prime