this post was submitted on 02 Jul 2023
192 points (94.0% liked)
Programmer Humor
19623 readers
4 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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 ofOption
s is that the final result will beNone
if any of the sequencedOption
s had a value ofNone
, otherwise it would be aSome
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 firstErr
that is encountered, otherwise it would be a finalOk
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.
All good, thanks for the explanation! :D