• work on infinite lists, eg: iterate, repeat.

There is nothing wrong with linear functions for infinite lists. Presumably they will eventually be used in an unrestricted context. But this is not an issue

• discard most of the elements, eg: head, find, null (or they require significant changes on the type signatures)

It's hard to justify linear head and null as they become identical to the corresponding pattern matching. find might, but it's not clear what the actual definition ought to be. You should re-export the unrestricted versions of these functions, though.

• are partial, eg: scan1, foldl1

There is nothing wrong with partial function (as long as they have HasCallStack 🙂 ), so let's have these.

Thanks @aspiwack , I applied your suggestions, with below exception:

It's hard to justify linear head and null as they become identical to the corresponding pattern matching. find might, but it's not clear what the actual definition ought to be. You should re-export the unrestricted versions of these functions, though.

I still think from an user perspective it would be surprising to import a linear module and get an unrestricted function, especially when there is a (admittedly not ideal) linear implementation too. So I tried to find a middle-ground, and implemented the linear versions:

head :: (HasCallStack, Consumable a) => [a] #-> a
tail :: (HasCallStack, Consumable a) => [a] #-> [a]
last :: (HasCallStack, Consumable a) => [a] #-> a
init :: (HasCallStack, Consumable a) => [a] #-> [a]

find :: Dupable a => (a #-> Bool) -> [a] #-> Maybe a

Especially find's implementation is pretty ugly; since for each element it has to first duplicate it, check one copy against the predicate, and then consume the other copy when the predicate fails.

I think this way things will be less surprising. Let me know if you still prefer the unrestricted versions instead of the above ones.

So I tried to find a middle-ground, and implemented the linear versions:

These are mostly useless though. Plus, they are not compatible with the corresponding non-linear version. Same as record projections: they require unrestricted arguments. Even in a linearly typed module. I think that these functions ought to as well. We shouldn't require programmers to import two modules just for the sake of having mixed linear and non-linear code (which is the norm in linearly typed modules anyway).

These are mostly useless though.

I agree.

We shouldn't require programmers to import two modules just for the sake of having mixed linear and non-linear code (which is the norm in linearly typed modules anyway).

I am not a fan of having to import multiple modules either. My omittance was mostly about providing a syntactic clue about whether something is working on linear or unrestricted values. Qualified imports are one way to achieve it, putting a suffix to the names would also work (but not pretty), or just having it absent from .Linear module is a strong clue that there is no linear version.

As you mentioned, whether a linear version of something is useful or not is a blurry line. Especially, for examples like takeWhile or dropWhile, I can think of them either way. So, I can imagine someone importing Data.List.Linear and assuming the head function to be :: Consumable a => [a] #-> a, and getting an error. It wouldn't even be clear that head is the issue, since the error messages point to the binding rather than the unrestricted use. So, it would take some cross-referencing docs to figure out one of the functions there is not linear on the parameter. I imagine that to be frustrating.

But, it is not a huge issue, and definitely not a hill I want to die on before the release. So I removed the linear implementations and re-exported the unrestricted ones from Data.List. We can always change our decision in the future.