I think the downvotes are because it kind of sounds like you didn't read the article and are saying the things that the author directly states as a "misconception":
"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."
Maybe you think the author is wrong, but your comment didn't read like you were addressing these points.
Or maybe the article isn't understandable. Sorry, I tried to read the article and just got confused and don't understand, what the article is trying to say. So it would be a good start to present the understanding one might get from that article and then get constructively corrected, where this understanding is wrong. In my eyes, this is the only way to understand a complex topic which isn't explainable in common language.
So great call out. My mention of the downvotes wasn't in reference to my comment, but into the parent I was replying to who is clearly newish to Monads. And their summary is actually fairly accurate.
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.
That's just a signature though, and the implementation could do so many things for complex and/or strange data structures.
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"
Please explain a parser monad in terms of flat map.
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.
> 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.
Not only did this 'answer' not reference any specific properties of flatMap; it didn't reference any specific properties of parsers either. I hold it wholly insufficient and incorrect.
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.