In a recent thread there was some brief, tangential discussion about using a few common FP abstractions within crystal.
I completely agree with @asterite in that just because language X does something, it does not mean that crystal should support it, or an implemention should be made. The language features and semantics available natively in crystal are different to other languages - hence approaches to problems should be based on these features and restraints, not those of another language.
Nilable types (and checks for this) are a perfect example. What’s provided by crystal’s type system and internal operators mostly removes the need for an Option/Maybe type (unless you really need to differentiate between the concept of nothing and
nil). This does not however negate the usefulness of other monadic types. Specifically Either.
As a toy project I popped together an either implementation the other day (P.S. @alex-lairan I wish I searched for your lib first). This lets you neatly model some operation that may fail. You can then continue to chain operations which apply as long as you stay on the good path, or just short-circuit otherwise. What’s important is each of these operations may themselves result in an error and the types will continue to represent this. When you are done, calling
#value? provides access to the result so that you don’t leak internal abstractions.
In the interests of making the best us of crystal’s internal features, what are some approaches here that others are using where you need to model errors, but may (for various reasons) want to do this at the type level rather than throwing exceptions?