Return more than one STArray from an ST computation?

[hdgarrood]

Given the type of runSTArray:

runSTArray ::
  forall a r.
    (forall h. Eff (st :: ST h | r) (STArray h a)) -> Eff r (Array a)

it seems to me that it's a nice alternative to freeze + runST, which would involve an unnecessary copy, but I can't see a way to take advantage of this if I want to return more than one STArray from the computation. This would be helpful, for example, for efficiently implementing functions like unzip. Can anyone think of a good way of addressing this?

[hdgarrood]

I just thought of something - what if we also exported this from Data.Array.ST:

runSTArray' ::
  forall f a r.
    (forall h. Eff (st :: ST h | r) (f (STArray h) a))
    -> Eff r (f Array a)
runSTArray' =
  unsafeCoerce

Then you could write:

newtype ArrayPair arr a = ArrayPair (Tuple (arr a) (arr a))
newtype GroupedArray arr a = GroupedArray (arr (NonEmpty arr a))

and then you could use these types for f to implement unzip and groupBy respectively with no unnecessary copying. Does that sound sensible?

[paf31]

A nitpick: I think you can simplify things a bit by getting rid of the a since it's not mentioned elsewhere:

runSTArray' ::
  forall f a r.
    (forall h. Eff (st :: ST h | r) (f (STArray h)))
    -> Eff r (f Array)
runSTArray' = unsafeCoerce

newtype ArrayPair a arr = ArrayPair (Tuple (arr a) (arr a))
newtype GroupedArray a arr = GroupedArray (arr (NonEmpty arr a))

Malicious users could sidestep runSTArray' by defining some f using the FFI potentially (by essentially emulating a type family), but I think that's probably ok.

[hdgarrood]

Great, thanks. This is what I ended up doing in the groupBy PR, as it happens. :)