I have no idea why this is downvoted.
For all the functor tutorials, it really is nothing more than the interface and rules that define map. And Monad is essentially flatmap.
That's was so absurd about all of this.
For all the functor tutorials, it really is nothing more than the interface and rules that define map. And Monad is essentially flatmap.
That's was so absurd about all of this.
"It is a common misconception that "monad is the same as flatmap", which has even made its way into some "monad libraries" in non-Haskell languages. flatmap is not "monad". flatmap is the particular implementation of the monad interface on lists. If you understand flatmap, you understand the monad implementation for the list datatype... you do not understand "monads" in general."
If you can read and understand this comment (https://news.ycombinator.com/item?id=27639779) then you understand 80% of the practical use of Monad.
And the majority of people who understand that comment, could now implement the flatMap/join/>>= for the "Maybe a" Monad. And could probably implement ">>" for it as well.
And if you can implement "bind" for a randomly requested Monad, while you may not know what a Kleisli Category is, nor be able to define the monad laws and might still make a mistake implementing one, you have the essential concept of a Monad.
Definitely not arbitrary but maybe not useful for many monads (??)
So in a sense yes it's "just" this function that could do anything following the signature.
But now you're in the same place you already were, looking at a simple type signature with massive hidden implications, and if you treat it like a list you'll miss those implications.
"flatmap generalized to a vast field of dissimilar types" is much more complicated than just "flatmap"
To be concrete, I'm talking about the kind with the semantics that if `Parser X` parses an `X`, and `Parser Y` parses a `Y`, `>>` between them parses an X then a Y. I propose that you must explain that in terms of flatMap in order to say that this is a correct understanding of monads.
flatMap() is a specific function that you already understand. It is the most common instance of a general fn pattern that is used for the specific data type Array.
The flatMap equivalent function when used on the data type Promise is called then().
The special function you are asking to understand ">>" is simply another instance of then(). This one still waits for the promise to complete - the only difference is that the lambda you pass to then() doesn't have access to the result of the previous promise.
If you're using >>/flatMap on a Parser datatype, instead of running the lambda after first promise has completed successfully, it "runs" it after the first parser has completed successfully.
flatMap and (all of its other data type specific names) are the essence of a Monad.
Well, the extra sauce on top of an Applicative Functor that makes a Monad; but the essence of an Applicative Functor is also part of the essence of a Monad, and the essence of a plain Functor is part of the essence of an Applicative.