3 ms·
I believe Monad is fine as a term, because you cannot describe it based on resemblance with real-world objects, as more conventional OOP design-patterns are doi
by bad_user 12y ago
I believe Monad is fine as a term, because you cannot describe it based on resemblance with real-world objects, as more conventional OOP design-patterns are doing. And I think that the name of a design pattern should be first of all unique and easy to remember and not necessarily descriptive, because the whole point of coming up with a design pattern is to grow the vocabulary of those using it and naming clashes are bad.
I do prefer "flatMap" to "bind", as practiced in say Scala, because it's a direct reference to this property: "m.flatMap(f) == m.map(f).flatten"
- dllthomas 12y agoI don't know enough Scala... "flatten" seems to be equivalent to "join" from Haskell/math - is "flatten" specialized to lists? For that matter, is "map"?
- bad_user 12y agoWhat do you mean by specialized? Don't know the equivalent of flatten in Haskell, but if you want a signature then it is something like: def flatten(m: M[M[A]]): M[A] Or another way of thinking about it ... flatten(m) == flatMap(m)(x => x) So basically, in order to define a monad, implementing flatMap is equivalent to implementing flatten. And I think that "flatten" as a verb is very intuitive, although intuitiveness is subjective since it's tightly related to familiarity - but flatten has been used in many languages as an operation available for collections and it works for monads in general just as well.
- dllthomas 12y agoSpecialized in the sense of a more restricted type. From your answer, it seems like "no" - though my Scala is superficial and rusty. The Haskell equivalent is join :: Monad m => m (m a) -> m a We also have the equivalent specialized to lists: concat :: [[a]] -> [a] And as you say, join = bind id = (>>= id). Incidentally, in math that function is the "eta" in the triple representing a monad.