Now linear type has arrived, is it worth writing linear function by default ?
I mean, I believe that most of the functions we wrote linear. We rarely don’t use parameter or duplicate them, so most function are about combining things.
Even if it is not most, it is likely a significant percentage.
So should we start writing all linear functions as linear, or is it just a waste of time.
2 Likes
Perhaps using Granule and Clean on some small projects could help answer that question…
1 Like
No. But the compiler should figure it all out by itself.
What do you mean ? – 20 char padding
Granule and Clean were both designed from the outset with support for linearity and uniqueness (as their syntax shows), whereas linearity has been retrofitted into Haskell (as that choice of syntax shows). So using Granule and Clean should provide more substantial experience-based points of comparison with regards to substructural types than using Haskell: “try before you buy”.
1 Like
Probably not, because linear types usage is not widespread, and there’s also the worry of making type signatures too complex for beginners.
That said, when looking at module Data.List.Linear from linear-base, I’m struck by how the signatures tell you more when compared to corresponding signatures from Data.List, at a moderate (to my mind) cost in signature complexity.
It’s nice to look at signatures like Int -> [a] %1 -> ([a], [a]) and know, just by looking at it, that the function doesn’t drop any element from the list. Or look at (a %1 -> Maybe b) -> [a] %1 -> [b] and know that it must be a filtering function.
7 Likes
One have to get used to the new syntax though 