Monadic vs. applicative traverse/sequence

FSharpPlus contains traverse and sequence. I assume they are monadic. Is there support for applicative versions? If not, would it make sense to add?

For details, see https://fsharpforfunandprofit.com/posts/elevated-world-4/#applicative-vs-monadic-versions-of-traverse

[gusty]

That blog post is misleading.

Applicative and Monadic versions are different internally, in terms of implementation, externally the sole difference should be that the Monadic version requires that the type is a Monad.

Since all Monads are Applicatives our implementation is based on the latter, to avoid unnecessary restrictions.

But having said that, it’s important to remark that contrary to what he says, both Applicative and Monadic implementations should return exactly the same results.

I think he’s misusing the names to signify that the applicative implementation is based on Applicative Validation, which is a different Applicative for errors. See https://github.com/fsprojects/FSharpPlus/issues/51 which is already implemented.

PS: You are not the first person I know that got confusing after reading that post, I think we should ask the author to rectify. He should find another name to distinguish, not just Applicative, maybe Accumulative.

[gusty]

Yes, I understand your concern but if you think about it, it’s a logical problem.

We can’t have two different implementations on the same type and use generic operators at the same time.

When you have two or more implementations on the same type there are 2 options:

• You don’t use generic operators, you create a specific operator for the implementation you want. This is the approach most non-generic F# libraries take, some of them use the same identifier for the function/operator but in fact they are different, they force you open different namespaces to switch between operators with the same identifier but different implementations.

• You choose one default implementation for the type and use a wrapper type for the other implementations. This is the approach we take here and also other generic libraries in other languages (Purescript, Scala, Haskell, Agda, Idris, etc).

Why didn’t we choose the Accumulative errors as the default implementation?

Because it’s not monadic. Had we choose that one we were not able to create a Result CE. Or we could have use the other implementation for the Monad as shown in the post, but that would break a lot of rules and would be impossible to reason about the code. Other libraries in other languages took the same path.

Now, we can consider some mixed functionality by providing non-generic operators namespaces. This is a path we never went into because this library started initially as a generic one, but it has evolved in the non-generic field as well, so at some point we could consider it. If you feel like, you can open a new issue proposing these changes.

Note this is not an issue that involves only applicative validation, same situation exists with seqs, lists, arrays (which have an alternative point-wise applicative ZipList), numeric types also have an alternative monoid that does multiplication instead of addition, function default to Writer but they could implement State as well.