4 ms·
Doesn't the "colors" concept also apply to concepts like error handling? E.g. Result, Option, exceptions... You have to "add colors", e.g. special map()s or wr
by the_gipsy 6y ago
Doesn't the "colors" concept also apply to concepts like error handling? E.g. Result, Option, exceptions...
You have to "add colors", e.g. special map()s or wraps.
A Result<a, err> cannot be chained with a pure fn and an Option<a> without adding colors. Or a fn that throws cannot be called from a pure fn that never throws, without adding colors.
Js promises do wrap try/catch in most cases, but I recall some unusual constructor that doesn't.
Rust doesn't have exceptions, so Result<> is standard. It's painless to mix .map() with .and_then(), however I do think this is a case of "coloring". You also have to "color" when chaining with Option<>, which sometimes is conceptually between a pure fn and a Result fn.
- pornel 6y agoIt doesn't, because you can wrap and unwrap Results at will, so you can change "color" of such functions, and you're never irrecoverably stuck with just one color. The original article's key point was about async forcing refactoring of all functions in the entire call graph just because a leaf function needed it. This doesn't apply to async or options in Rust, because Rust functions can use these features without exposing that fact to their callers.
- the_gipsy 6y agoThat's what I'm saying, you can change the "color" of all these including async, but you still have to do that. There is no single Monad type from which you can build and chain, you always have to color some calls.
- pornel 6y agoNo, you can abstract over "color". You can implement a trait that lets you call both sync and async functions in the same way. You can with the same code and same syntax, get results of either `Fn()->T` or `Fn()->Future<Output=T>`.
- the_gipsy 6y agoYou are right, it doesn't "poison" your code, you can always wrap or map it. I guess I was just going off some tangent.