Joachim Breitner wrote:

I’m consdering to change some performance critical code from Vector to MVector, hopefully avoiding a lot of copying and garbage collecting. But it seems that the Data.Vector.Mutable interface at http://hackage.haskell.org/packages/archive/vector/0.9/doc/html/Data-Vector-... is quite limited; e.g. I am missing simple functions having type modifyM :: PrimMonad m => (a -> m a) -> MVector (PrimState m) a -> m () that would do something with each element in the vector.

Is this an indication that such use is actually not desired, or is it just the case that nobody has developed that yet?

In general you should try to work with immutable vectors as much as possible. Done properly you shouldn't lose much performance that way. However, sometimes an operation is just much easier to express and faster with the MVector interface. In these cases you can escape to the mutable interface using 'create', 'modify', 'thaw' and 'freeze'. Don't forget that you lose fusion that way, though. In other words: Don't use MVector exclusively. Use it only when you really need it. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

Joachim Breitner wrote:

Hi,

I’m consdering to change some performance critical code from Vector to MVector, hopefully avoiding a lot of copying and garbage collecting. But it seems that the Data.Vector.Mutable interface at http://hackage.haskell.org/packages/archive/vector/0.9/doc/html/Data-Vector-... is quite limited; e.g. I am missing simple functions having type modifyM :: PrimMonad m => (a -> m a) -> MVector (PrimState m) a -> m () that would do something with each element in the vector.

At the moment, the best way to do this is: modifyM = Data.Vector.Generic.Mutable.transform . Data.Vector.Fusion.Stream.Monadic.mapM Note that transform will return a new vector but that is guaranteed to be a slice of the original one. Since mapM doesn't change the number of elements, you can safely ignore the return value as it will be always your original vector.

Is this an indication that such use is actually not desired, or is it just the case that nobody has developed that yet?

The latter. I need to come up with a nice mechanism for specifying loops over mutable vectors but this isn't entirely trivial and I haven't had enough time to really work on this lately. Roman