Ah, so is it right to say it’s an abstraction of how functions are sequenced? I could kinda see that idea in action for I/O and Async (I assume it evaluates functions when their corresponding async input is ready?)
I think that’s a reasonable enough generalization, yeah.
I’m sorry though, I seem to have given you incorrect information. Apparently that library does not have monad instances, so it’s a bad example (though the Concurrently type does have an applicative instance, which is similar in concept, just less powerful). For some reason I thought they also provided monad instances for their API. My bad.
Perhaps it would be better to use a much simpler example in Option. The semantics of the sequencing of Options is that the final result will be None if any of the sequenced Options had a value of None, otherwise it would be a Some constructor wrapping the final value. So the semantics are “sequence these operations, and if any fail, the entire block fails”, essentially. Result is similar, except the result would be the first Err that is encountered, otherwise it would be a final Ok wrapping the result.
So each type can have its own semantics of sequencing operations, and in languages that can express it, we can write useful functions that work for any monad, allowing the caller of said function to decide what sequencing semantics they would like to use.
Ah, so is it right to say it’s an abstraction of how functions are sequenced? I could kinda see that idea in action for I/O and Async (I assume it evaluates functions when their corresponding async input is ready?)
I think that’s a reasonable enough generalization, yeah.
I’m sorry though, I seem to have given you incorrect information. Apparently that library does not have monad instances, so it’s a bad example (though the
Concurrentlytype does have an applicative instance, which is similar in concept, just less powerful). For some reason I thought they also provided monad instances for their API. My bad.Perhaps it would be better to use a much simpler example in
Option. The semantics of the sequencing ofOptions is that the final result will beNoneif any of the sequencedOptions had a value ofNone, otherwise it would be aSomeconstructor wrapping the final value. So the semantics are “sequence these operations, and if any fail, the entire block fails”, essentially.Resultis similar, except the result would be the firstErrthat is encountered, otherwise it would be a finalOkwrapping the result.So each type can have its own semantics of sequencing operations, and in languages that can express it, we can write useful functions that work for any monad, allowing the caller of said function to decide what sequencing semantics they would like to use.
All good, thanks for the explanation! :D