Introduce Data.VM.Linear and Data.LArray.Mutable.Unlifted.Linear

[utdemir]

Relevant #312 .

This PR introduces a new mutable linear array type called LArray (Data.LArray.Mutable.Unlifted.Linear), which contains linear elements. And it uses that to implement a VM type, which is our V on a mutable backing store.

There're many design decisions, so I decided to create a draft PR before working more on this.

The new Data.LArray.Mutable.Unlifted.Linear is mostly a copy of Data.Array.Mutable.Unlifted.Linear; with changes to preserve the linearity of the elements:

• It is meant to be used with the update function; and get and set functions require Dupable and Consumable constraints.
• Functions like lseq and dup2 over arrays consumes or duplicates the elements one by one.

And we have VM implemented as a length-indexed wrapper over the LArray. It uses the type-level utilities from the original V module and provides a similar make and elim functions; the main difference being make function taking a linear callback.

And here is the missing parts (hence this is yet a draft):

• Comments on whether this is useful (having Data.Array.Mutable.Unlifted.Linear, a separate VM type).
• There's a bunch of unsafe code, but no tests. We should have some.
• We have to decide whether we should use the new VM on the Dupable class. I feel like it would be a good default (based on Using a mutable backing store (such as Array) for V #312), but we have to have an efficient Applicative instance.
• It'd be good to try out our lenses here.

[aspiwack]

We have to decide whether we should use the new VM on the Dupable class. I feel like it would be a good default (based on

What would be the type of dupVM?

[utdemir]

What would be the type of dupVM?

Very good point; it can not be a #1-> VM n a because then we can get an unrestricted VM. So it has to be something like a #-> (VM n a #-> Ur a) #-> Ur a, which is not pretty (and likely more restrictive than the curent dupV).

For a similar reason, something like a :: V n a #1-> VM n a is also not possible.

What do you think?

[utdemir]

@tbagrel1 Do you think this can still be useful, especially after #360? Please feel free to close this otherwise :).

[tbagrel1]

I think that it still makes sense to add Data.LArray.Mutable.Unlifted.Linear because in #360 and the following related PRs, we couldn't implement fromReplicator for Data.Array.Mutable.Linear. Indeed, the mutable arrays currently available in linear-base have unrestricted elements, and Replicator a is only able to provide restricted elements (although with no limit in number of copies).

Could you tell me what does VM would bring over Data.LArray.Mutable.Unlifted.Linear? I'm pretty lost in all the array-like structures we have at this point.

[utdemir]

Could you tell me what does VM would bring over Data.LArray.Mutable.Unlifted.Linear?

VM is length-indexed, LArray's are not. As far as I can remember this is the only difference. Whether we need this or not is a different question :).

I'm pretty lost in all the array-like structures we have at this point.

Agreed. I do believe Arrays containing linear elements are useful, but it was unfortunate that we couldn't express this polymorphically, instead resorted to completely new types. That's why I was hopeful with the new Replicator design.

---

Anyhow, I'll leave this to your discretion, feel free to close it if there's no strong need :).

[tbagrel1]

I'm not a user of linear-base myself at this point, so I don't really feel legitimate to say what we need and what we don't need 😅. But right now I don't see a strong point for adding VM. Compile-time-known-sized array are somewhat unpractical to deal with, especially when they are mutable. So I think that people won't really use them for large n, which is when having a mutable store starts to bring performance improvements (maybe for cryptographic applications?). V n a behaves rather like a n-ary tuple given its API at this point.

However, I think that LArray is a more basic type that is really missing in linear-base. We definitely want to have these functions:

LArray.fromReplicator :: Int -> Replicator a %1 -> LArray a

LArray.fill :: Dupable a => Int -> a %1 -> -> LArray a
LArray.fill n = fromReplicator n . dupR

that we couldn't write for Data.Array.Mutable.Linear

---

Anyway, I think that it would be interesting to add some Array-like memo/2-axis table to #376 #368