Repository navigation
Folds over mutable vectors #326
Description
Activity
I am definitely in favor of all or some these:
mapM_andforM_instead oftraverse_, since the latter name would not be consistent with the pure versionsimapM_andiforM_foldlM_andfoldrM_ifoldlM_andifoldrM_
With respect to
traversethat does mutation, I think I'd vote for a version that mutates the same vector in place. This of course would make the mapping function to produce elements of the same type:traverse :: (a -> m a) -> MVector (PrimState m) a -> m ()
Which means it would be slightly different from
traverse, as such maybe we should come up with a good new name for such function.A version that creates a new vector isn't as useful, since you can already just as easily achieve it with:
unsafeFreeze >=> mapM f >=> unsafeThaw. I think there are rewrite rules that will ensure thatmapMwill get specialized toPrimMonadmaking it efficient. But, as you said we can discuss this part more in a separate ticket.Reacted by ˌbodʲɪˈɡrʲim and konsumlammAgree with the mutable traversal. This should probably be called something like
modifyTraverseortraverseModify.Incidentally, maybe it would also make sense to have
modifyM :: MVector (PrimState m) a -> (a -> m a) -> Int -> m () modifyAll :: MVector (PrimState m) a -> (a -> a) -> m ()And then, by extrapolation, the traversal would be called
modifyAllM :: MVector (PrimState m) a -> (a -> m a) -> m ()Reacted by ˌbodʲɪˈɡrʲim+1. We have several issues asking to extend API for mutable vectors
I noticed a reoccurring help function across several applications that I've written, and I think it would be nice to have these in
vectoritself:The implementations are both straightforward, and I'm happy to implement this if others find it worthwhile. There is the possibility of a
traversethat either (a) mutates the vector in-place or (b) creates a new mutable vector. There's more room to disagree there, so if anyone is interested in that, I think that discussing it on a separate issue would be better.