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.
Well fmap is nothing like accumulate. However, transform is like fmap(at least how it is used in Boost.Fusion, Boost.MPL, and Boost.Range). The only difference is that in hana, fmap can go beyond just sequences. It could be applied to boost::optional, boost::future, pointers, etc(although you could just adapt these type as sequences), but transform still works in a similar manner, so I don't see a problem with calling it transform.
Hana is fundamentally functional, it uses rather abstract concepts and that's what makes it so powerful. Truth is, "Sequence" and "Container" concepts are easy to understand but they only get you so far; they are not general enough to be used as building blocks.
I believe Alex Stepanov would like to have a word with you ;)
"Container" isn't really a concept in the STL. "Iterator" is. And the concept of iterator was derived from studying runtime algorithms as executed by hardware. There's no reason to think that studying compile-time algorithms as executed by modern C++ compilers would lead to the same abstractions.
I agree. I was referring to being able to make algorithms and sequences orthogonal, which should still be possible at compile-time. -- View this message in context: http://boost.2283326.n4.nabble.com/Re-GSoC-Boost-Hana-Formal-review-request-... Sent from the Boost - Dev mailing list archive at Nabble.com.