Introduction of a Either / Result

[KristianBalaj]

The stdlib is currently missing one of the essential types i.e. Either<a, b>.

[rvcas]

@KristianBalaj we've actually had a long convo about this before and we probably won't have an Either type in stdlib. There's been conversations about just supporting Result<a, b> but then that's another conversation about how to treat errors as values which just isn't the case at the moment. In any case, Either is more a candidate the prelude instead of stdib. One thing to keep in mind is that just cause something is commonly considered "essential" in some functional programming languages that may not be the case for aiken. I don't actually have a haskell background for example so I never even considered having Either in the prelude.

[KristianBalaj]

Fair. Thinking about it further it's maybe not that necessary to have this from my point of view. I'm currently using it in datums to represent some state but maybe having a custom type with multiple constructors and custom functions is a better approach for readability than using a general Either type.

So I don't have a reason to fight for having it in the prelude right now 😄

[KtorZ]

The thing is, it may sounds like a good idea until you realize how most on-chain ends up being written. Because everything on-chain has a cost, any abstraction that 'gets in the way' is instantly frowned upon.

The thing with applicatives such as Either or Option (Maybe) and all the other typical algebraic structures found in FP are useful to manage side-effects or handle errors. However, there's no side-effect in Aiken whatsoever (apart from tracing perhaps, but I dare anyone to build a Writer monad or a Contravariant Comonadic logger around the tracer). As for error handling, validators don't themselve leave room for nuances: they either pass or fail. Thus, error handling is more or less just about error deferring which, in the vast majority of cases doesn't bring anything: when you expect the output to have X Ada, if it doesn't there's not much point handling the error. You can fail right away and the validation is failed anyway.

This also stems from how errors in Plutus aren't values, but are strict bottom. They terminate the execution and you can't handle error signals. There's no "catch". This doesn't really encourages the management of errors and the extra cost that goes with it.

---

Having said that, I still see a world where having an applicative-like Either (or more like Result), would be useful. In particular, during development, to ease debugging and tracking of a validator state. This is why we're doing our best to keep functions of the standard libraries pure; returning Option<...> instead of being partial. I'd like to leave the room open for a result library in Aiken that can allow a more monadic approach to writing contracts, instead of using expect every 2 lines, in hope of producing better errors on failures.

This could very much exist as a separate package. I don't see it being in the Prelude to be honest because such a data type is only truly useful with all the accompanying functions.

[rvcas]

Yea well said. That's the vibe. And it's also nice to have some syntax to facilitate errors as values which we don't have atm. Things like try or ? in rust.