text VS containers

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.

"Make invalid laziness unrepresentable" means you should use strict versions of container types instead of lazy ones. However, for better or for worse, sometimes the "strict version" of a data type is not actually a strict data type, it's just a strict API to the lazy type. Examples include Data.Map.Strict (not Data.Map or Data.Map.Lazy) or Data.HashMap.Strict (not Data.HashMap.Lazy) (sadly there is no Data.Sequence.Strict but perhaps there will be one day).

Indeed it's rather subtle. See https://github.com/haskell/containers/issues/752 for more discussion on the matter. Nonetheless, I believe it is "spine strict" in the sense that thunks for all values always exist, even if the spine that holds them can be rearranged due to laziness.

Note that the list index operator has O(n) complexity. Ideally you'd want to use something like Seq from the containers package

Edison and containers both have sequence types that support efficient, cons, snoc, viewL, viewR, append, map, and length.

containers

Calling linked lists Haskell's "primary data structure" seems off-base to me. Yes, there's String, yes, there's built-in syntax for List... but there's also everything in containers, and vector is pretty easy to use in practice, though it would probably be good for more learning material to mention it more prominently.

Haskell has much more sophisticated immutable data structures, you can find them in the "containers" package: https://hackage.haskell.org/package/containers

I asked this on the libraries mailing list but thought posting here would bring in potentially more responses. I made a recent change to the behaviour of lookup and find (see here for more details: https://github.com/haskell/containers/pull/800).

Rust has nothing on Haskell. containers, which might as well be considered part of the standard library, has been out for almost 14 years and is still 0.x