Yeah, I haven't done any Haskell but from what I understand "a monad" is just a type that lets you call `.map()` on it and do the normal thing that `map()` does. Would it be wrong to call it `mappable`? That would be a much clearer name.
A monad could be described as "sequencable/chainable", but that metaphor is quickly breaking down as there as so many ways in which monads show up.
These days you should probably add Foldable and Traversable to that list, as they are closely related and appear throughout the standard libraries and even in the Prelude.
Traversable is a generalization of Functor to include Applicative effects. It reduces to Functor if the Applicative happens to be the Identity type.
Where Functor and Traversable replace values one-to-one while preserving structure, Foldable represents reducing operations (folds) which consume the values from a structure in some defined order to build up a result. This includes basic functions like sums and products, as well as more complex operations like `sequence`.
Hmm well it might break down but simply by choosing a better word you've helped me understand what a monad is more than any article I've read on the matter.
Even to just be able to rapidly identify why having a thing that .map()s is a meaningful object represents the sort of experience with and abstraction of these concepts that'll put you ahead of the game for understanding monads.
Monad should be `FlatMappable`. I found this great article where they use exactly these terms to explain it:
https://dev.to/joelnet/functional-javascript---functors-mona...
If people are using different terms to explain your confusing terminology then... maybe the confusing terminology is not very good.
On the other hand, if I say "it's a monad" then people who have encountered the term before know what I mean (even if they've had no need to understand monads in depth) and people who have not will successfully find information about the right thing if they search for it.
Monads have a particularly bad reputation for being hard to learn, despite appearing in non-general form in every modern language. Since people seem to have little trouble grasping the way in which futures, streams, and options work I don't think there's really such a great challenge involved - but the culture of running screaming from the mere word doesn't help matters in the least.
For what it's worth, "functor" properly describes the combination of a type and its relevant .map() function. It's (common) shorthand to refer to just the type as "a functor" when there's a unique, well-known functor that utilizes that type.
So, we could be more precise, of course. But also if you just throw up your hands when someone says "a list is a functor" then you're fighting a difficult battle.
(The mathematical basis helping you get deeper insights into it is just a bonus, albeit IMO a valuable one.)