...

[pfultz2] Yet it uses a lot of foreign functional concepts. Despite what google says, boost libraries are built around mostly C++-like 'interfaces'. I don't think its bad to introduce some functional-interfaces, but I know in the past libraies that libraries that were very functional were rejected from boost, because many people didn't grasp the purpose of them. So introducing a lot of functional interfaces on the surface of a library can hinder its adoption.

This is a solid caution. Louis, it would be worth your while to review the comments made regarding the Boost review of FC++ some years back, in order to prepare you for the kinds of questions and concerns that primarily imperative-style developers raise.

[Louis Dionne] That is sad, because the functional concepts are exactly what makes Hana so powerful. Some problems are well suited for functional programming, and some are not. Metaprogramming is __inherently__ functional, and it's about time people embrace it.

+1. On a related note (not quoting that other discussion here, but there's been some other postings on the subject), inventing new terminology for well-established programming concepts is not merely pointless, it's actually harmful. If C++ already has an established name for the programming concept, that would be a justifiable reason to use that other name instead of the standard functional programming name. So, it would not at all disturb me if "maybe" ends up being called something like "optional" (C++ is not even alone: Scala calls it "Option"). However, http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf serves as an existence proof that "monad" has been in use within the programming community since at least 1991. C++ doesn't directly model this concept elsewhere in its most generic form (notwithstanding http://bartoszmilewski.com/2014/02/26/c17-i-see-a-monad-in-your-future/). In this case, I am aware of no justification for using any other name. Dave