text VS bytestring

String is a linked list of UTF-32 codepoints, which is just as bad as it sounds. Haskell programmers usually use Text from the text package instead.

This is the first release that was executed via the new GitHub CI. Everything went smoothly, except for an unexpected packaging bug on windows due to text-2.0 linking against libstdc++ by default.

In addition to what's mentioned, the "default" libraries people use are often not the best-performing ones. E.g. Data.Vector.Hashtables is often much faster than Data.HashMap.Strict (which again is typically faster than Data.Map). And we find performance papercuts in common libraries that may simply be due to not enough people optimising for speed.

Used by nearly every Haskell project: https://hackage.haskell.org/package/text 60% of the modules are ".Internal".

text

Here is a representative patch for text: https://github.com/haskell/text/pull/365/commits/37a2157245457a287d638bbceb472fe93b71f224 Hopefully it clarifies why achieving C performance is problematic even if you have enough primitive operations.

I want to run an app in a Docker container, but detached. This causes getLine to throw an EOF exception, since the terminal detaches. That is, if I understand this thread correctly https://github.com/haskell/text/issues/258.

The documentation is itself fairly funny, for those who don’t care to click ahead:

> This "function" has a superficial similarity to ‘unsafePerformIO’ but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet.

> Witness the trail of destruction:

    https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7

If you bring in efficient strings from bytestring, densely packed arrays from vector, and an in-place sort from vector-algorithms, you can bring it down to 275ms (uses 19MB of mem).

bytestring

Note that this release is broken for Windows.

I've opened https://github.com/haskell/bytestring/issues/455 so the situation can be improved. You're very welcome to chime in on the discussion or to contribute some of the missing documentation yourself! :)

Highlights from the changelog:

Well, ByteString in particular should not have an IsString instance in a new report. That's pretty clear by https://github.com/haskell/bytestring/issues/140 : the concensus is that there is no good solution right now, but it should not have gotten an IsString instance in the first place. If a theoretical new Haskell Report 202x includes OverloadedStrings (as it should) to handle string literals analogously to numeric literals, I'd expect it to not give ByteString (which is really just a collection of octets) an IsString instance, with all it's issues and rattail due to the encoding question being implicitized.

Standard streaming libraries. They are being written by people that make the effort to understand performance and I have a hope that they make sure their streams run in linear space under any optimizations. It is curious and unsettling that we have standard lazy text and byte streams at the same time — and the default lazy lists, of course. I have been doing some work on byte streams and what I found out is that there is no way to check that your folds are actually space constant even if the value in question is a primitive, like say a byte — thunks may explode and then collapse over the run time of a single computation, defying any effort at inspection.