What is the most popular optional / alternative monad?

[davidyu2023]

It seems more natural to use Eff<A> or Aff<A> during the construction of the objects as more side effects are involved. After that I found myself using Validation<FAIL, SUCC> almost exclusively. It seems the absence of a value in most cases would suggest something is wrong and an error message should be reported. I do use Option<A> and Try<A> occasionally.

Am I missing something obvious? It seems to me Validation may not be as important as Option that gets an async version. I wonder how you guys use the monads.

[evermanwa]

EitherAsync<A,B> is one that I find myself using a lot in my web apis in conjunction with linq. OptionAsync is another that I find myself using a lot as well. Validation is a new one for me, and I'm trying to do better about implementing it. I've known about it for a while, but it wasn't my main focus.

[davidyu2023]

Either seems similar to Validation as they both have two alternative values. Do you typically represent the Left as some sort of error, and use it trace your program so that you know where things go wrong?

[bmazzarol]

Always pick the Monad that provides the most limited set of guarantees required to accomplish the goal.

If all you need is to detail that a function might not return a value, but will never fail, just use Option.

If you want to outline that it can return 1 of 2 values, use Either.

If you want to describe a function that returns 1 or many failures, use Validation. (This one should not come up as much)

I would recommend looking through the API documentation, its all very good.

IMHO, the async variants of Either, Options and Try are all a mistake. If you want an effect monad, use Eff and Aff.

More than happy to talk to more specific cases and then talk through why a particular Monad might be better or worse.

[CK-LinoPro]

Validation and Either are structurally identical, so most of the time it's easy to get away with Either.
The difference lies in its implementation of a behavior called Applicative Functor (defined by a function (<*>) :: f (a -> b) -> f a -> f b in Haskell terms, https://en.wikibooks.org/wiki/Haskell/Applicative_functors).

When you have monadic computation like the following, it shows fail-fast behavior. It just stops at the first error.
This works for any alternative monad.

var result =
  from a in FetchA()
  from b in FetchB()
  select a + b;

For most monads, the Applicative Functor instance is just the same as its Monad instance and language-ext doesn't even implement it explicitly for Either.
For Validation however, the Applicative Functor instance allows you to continue the computation and collect further errors before failing.
language-ext provides an overload of .Apply(...) that is a little more convenient to use in C# than Haskell's (<*>).

The following example only works for Validation and gives you both errors if FetchA and FetchB happen to fail.

var result = (FetchA(), FetchB()).Apply((a, b) => a + b);

Applicative Functor takes away the ability to do conditional computation that you get with Monad, i.e. FetchB cannot depend on the result of FetchA.

There is also a difference in how Sequence and Traverse work on Either vs Validation because they effectively call the Applicative Functor implementation. Again, for Either it's fail-fast, while for Validation it aggregates all errors.

I tend to write my own error handling monads with a fixed error type, applicative behaviour, lazy evaluation and optional support for asynchronous computations, sometimes with an Reader or Writer implementation thrown in there.
Aff and Eff follow a similar approach.
https://github.com/louthy/language-ext/wiki/Does-C%23-Dream-Of-Electric-Monads%3F shows you how to do this.
For basic implementations, I prefer Either just because it's more common and I can easily convert it to Validation.

[louthy]

language-ext doesn't even implement it explicitly for Either.

Everything you wrote is correct apart from this. All monads have Apply and Action implemented. They're more like the classic <*> operator than the convenience overloads in Validation. This link will take you to the Either applicative implementations - scroll down, there's lots of overloads.

However, it doesn't give you a huge amount (as you say), they're synchronous and non-monoidal, so you don't really gain anything over using monadic bind. There's some unit tests showing applicatives in action for Either.

One thing that is coming in version 5 (if I can get it right), is monad-transformers. That will allow the 'stacking' of various monadic types, therefore collecting all of their behaviours. This means you'll be able to create a new monad-type and pick-n-chose the exact functionality you want it to have. So, there'd be no need for TryOption for example, just combine Try and Option.

Below are some examples from my prototyping project. The final version may look nothing like this, so this is just to whet the appetite more than anything.

// Either monad created from EitherT monad transformer and Identity monad
public record Either<L, R>(Transducer<Unit, SumTransducer<Unit, L, Unit, R>> Morphism): 
    EitherT<Identity<Unit>, Unit, L, R>(Morphism)
{}

// Eff monad created from EitherT monad transformer and the IO monad
public record Eff<Env, A>(Transducer<Env, SumTransducer<Unit, Error, Unit, A>> Morphism) :
    EitherT<IO<Env>, Env, Error, A>(Morphism)
{}

// Aff monad created from EitherT monad transformer and the Async monad
public record Aff<Env, A>(Transducer<Env, SumTransducer<Unit, Error, Unit, A>> Morphism) : 
    EitherT<Async<Env>, Env, Error, A>(Morphism)
{}

[CK-LinoPro]

@louthy Thanks for your correction. I think I forgot about those Apply overloads because they can be quite noisy in contrast to the overload for Validation that works more like liftA2.

Monad transformers would be a huge game changer, you got me excited.

[bmazzarol]

@davidyu2023 I would only add one thing to what @CK-LinoPro has outlined above.

I think it is important to try and make function signatures as accurate as possible.

If a signature declares Validation as a result, it indicates to the caller they need to handle potentially multiple failures.

If this is not the case, IMHO it's better to be more specific, it's always easy to change to a more powerful type when the requirements dictate it.

[davidyu2023]

Thanks to everyone! This is great and I will switch from Validation to Either as my primary alternative monad.