> So really monads are essentially an abbreviated syntax? Chaining functions, where (some of) the arguments are hidden from the language syntax and inserted by the compiler?
I recently wrote a note related to this that had a useful exchange:
>> When you see a "do" block, where do you look to figure out what it's actually doing?
> If you need to know, you look at what consumes the result. If it's abstract (say it's a top level binding `... -> m a` where the m is abstract) *you don't _need_ to know "what it is actually doing" - it should be correct for any choice of* `m`.
The behavior, and the "laws" or perhaps general far-reaching properties, are the more important part of Monads I think.
That's a part of it, for instance see:
https://philipnilsson.github.io/Badness10k/posts/2017-05-07-...
I recently wrote a note related to this that had a useful exchange:
>> When you see a "do" block, where do you look to figure out what it's actually doing?
> If you need to know, you look at what consumes the result. If it's abstract (say it's a top level binding `... -> m a` where the m is abstract) *you don't _need_ to know "what it is actually doing" - it should be correct for any choice of* `m`.
The behavior, and the "laws" or perhaps general far-reaching properties, are the more important part of Monads I think.
> How does that relate to “pipe operator” as in https://github.com/tc39/proposal-pipeline-operator
The items in the pipeline don't have a set of laws that let you know what's going on for sure without looking at the implementation I guess.