linear-base VS text

Thanks for your interest in linear types. The sort of overarching answer is that the Covid crisis has put a serious wrench in our plans. There has been very little progress on the implementation in the past 2 years, I'm afraid. I hope to slowly pick up the pace again this year. But I make no promise as to specific plans just yet. When we have more visibility, we will publish a roadmap. This is not to say that nothing has happened at all: linear-base is getting a pretty significant release any day now, David Feuer (no affiliated with Tweag) has created linear-generics, an implementation of Generic which is compatible with linear types (there is a surprisingly subtle issue with Generic1, in particular, that I don't understand very well, so won't try to explain), we co-wrote two academic articles as well.

Handle is defined in terms of UnsafeResource (in linear-base). This is where the linearity checking "stops". If you pattern match an UnsafeResource then you have to make sure that you correctly close/free it. Luckily, this only has to be implemented once in an internal module and is not exported in the public interface.

If you are referring to the specific relative monads discussed in this issue. We'll need to improve inference in the compiler first.

The optics sublibrary is not very developed yet. Because our arrays, which are one of the principal use-case, require a special kind of lens which we haven't managed to produce without too much code duplication yet. The design space is discussed in this issue.

So to write a function f :: a %1 -> () you have to traverse the whole datatype a, see the Data.Unrestricted.Internal.Consumable and Data.Unrestricted.Internal.Instances, which introduces a type class consumable which implements exactly this functionality.

I think the solution to the problem with empty might be to use the Ur (for "unrestricted") datatype from linear-base:

Trying to run empty Ur shouldn't typecheck, because the Ur constructor is not linear. This seems to be an idiom used in other places of linear-base.

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.

u/snoyberg laments here that a consequence of Text using unpinned memory is that the FFI can't operate directly on it. However, there do appear to be some places where foreign imported functions are called on the underlying unpinned ByteArray# (see how Text.copy calls this).