Andrew Martin

I think the only reasonable thing to do in `primitive` is to use the primop that GHC provides. Optimizing the implementation further is a GHC issue, not a `primitive` issue....

Thanks for the feedback from both of you. It seems like weakening the constraints on the existing functions would be bad for multiple reasons. Would introducing something like `itraverse`, which...

@cartazio Sorry I wasn't clear. What I was asking is if it's alright to have a function that operates on immutable vectors that does not fuse.

The original reason I brought this up was because the indexed traversal `imapM` has a `Monad` constraint. It would be nice to have `itraverse`, which would weaken that to `Applicative`.

Agreed. I'm worried that doing this for `primitive-0.6.4.0` would break people's stuff since these modules export identifiers that may conflict with `Control.Concurrent.MVar` and `Foreign.Ptr`. But in `0.7`, this should happen.

With `Data.Primitive.Ptr`, it's definitely more of an "alongside" relationship, since the `Ptr` functions from `base` use `Storable`, and the ones in `primitive` use `Prim`. Plus, we use the same `Ptr`...

I'm fine with removing this. Or probably what I'll actually do is just release it in a different library named `primitive-mvar`. I've used explicit concurrency inside of ST only once...

Yes, those as well. And `MutVar`. We cannot do `PrimVar` at the moment though because we would want it to lower to an unlifted newtype `PrimVar#`, which cannot exist in...

Thanks!

It's worth pointing out that in your first post, you gave instances for `Cofree` and in the second one you gave instances for `Free`. I think the `Cofree` instances are...