Future also doesn't obey the monad laws for not being RT and that causes a lotttt of complexity.
Most all the theorist/logician/algebraist-turned-programmer folks I know all feel more-or-less the same way.
Just explain the pattern in english. Might as well call it a FooDeBar. Giving axioms and such is usually a waste of The Man's money and my time.
That said, I think it's extremely valuable to see this sort of thing in an academic or side project/enrichment activity setting. The mindset and mental model are fantastically helpful. See dshnkao's post, for example.
1. Don't use terminology from academic category theory / abstract algebra in computer programming
2. But if you haven't studied these things, and you are a programmer, it might be very enlightening to do so.
Is that right?
Woah there!
But otherwise, yes.
Most working mathematicians have seen category theory and borrow bits and pieces of notation and such. But most of their work is done in far more concrete settings.
Working programmers should adopt the same arrangement.
It's a subtle position, but not an inconsistent one. I promise :-)
Monads should never have escaped Haskell.
They should have put them in a monad.
You can derive `map` from these two other functions so it doesn't need to be part of the interface.
Confusingly, map in scala is fmap in Haskell