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

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2014-07-30 17:53:50

pfultz2 <pfultz2 <at> yahoo.com> writes:

> 
> > 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