pfultz2
Then again, if the interface of hana::fmap is nothing like the interface to std::accumulate, it could lead to confusion. The MPL names work in part because MPL is STL-ish design (containers/iterators/algorithms).
Just throwing that out there. No strong feelings. Naming Is Hard.
Also, I would like to mention that some names don't have exact equivalents in C++. For example, `bind` could be called `flat_transform`, however, that really only makes sense for sequences. Although, I do think, it would be better not to call it `bind` since it already means something else to C++ programmers, so another name could avoid confusion, I'm not sure what that name would be(perhaps `apply` or `compute`?).
I agree that `bind` isn't a good choice. I'll think of something, but `apply` and `compute` are out of question because Monads are not computations; that's just one metaphor.
Also, I think it would be better to call the `Monad` concept, `Computation` or something like that, since monad doesn't mean anything at all outside the FP community.
First, I find Computation to be too reductive. Second, I don't want to rename a concept that's well known in FP and unknown in C++ to something else that's unknown in C++; I'd rather keep the well known FP word. Anyway, the day where all C++ programmers will know Monads is coming, but DQMOT.
Just some additional thoughts and suggestions. Naming, of course, is hard.
Yes it is! Louis