Re: [boost] [GSoC] [Boost.Hana] Formal review request

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: pfultz2 (pfultz2_at_[hidden])
Date: 2014-07-30 15:17:35

> 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-tp4665622p4665836.html
Sent from the Boost - Dev mailing list archive at Nabble.com.