Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-07-29 20:37:42
On 7/29/2014 12:23 PM, Louis Dionne wrote:
> Edward Diener <eldiener <at> tropicsoft.com> writes:
>> But I do not understand from your documentation how your library relates
>> to Boost MPL. The Boost MPL library is about manipulating and creating
>> types at compile time, and creating logic paths again at compile time to
>> manipulate types. All of this is encapulated by the MPL's notion of
>> metafunctions to do compile-time programming. But I cannot get from your
>> documentation any of the MPL equivalence of how any of this is done with
>> your library. Is your library meant to duplicate/replace this MPL
>> functionality in some way ? Or is it meant to do something else entirely
>> not related to compile-time programming ?
> I had started to reply with a lengthy explanation of how it works, but that
> would not fix the problem because it is now clear that my documentation _is_
> the problem. I'll improve it, make it more explicit and then post back.
>> I am only asking this because I had been told that your library is at
>> the the least a replacement for MPL compile-time type manipulation
>> functionality using C++11 on up.
> It is, and it's also a replacement for Fusion and hence many other
> metaprogramming utilities. In particular, I'll write a cheatsheet
> showing how to do everything in the MPL and everything in Fusion
> with Hana.
> Thank you for taking the time to read the documentation (I assume you did)
> and give me your feedback.
Please consider also that you are using terminology in the present
documentation which does not relate to C++ very well, although it may
relate to Haskell for all I know. If you rework the documentation please
use C++ terminology for things. As an example you referred to Type<T> as
an object when in C++ it is a class. You also refer to type classes and
data classes but C++ has no specific meaning for either of those terms.
Also while it is useful to give syntactical examples you should explain
what is occurring in C++ and not in some hypothetical Haskell-like
functional programming language which a C++ programmer does not know. In
other words no matter how brilliant or clever your library or your
constructs are, you need to explain what functionality does what things
and not just that some syntax does something but another similar syntax
does something else entirely. Because in actual use if a user of your
library chooses to use some syntax, without understanding what the
underlying functionality actually accomplishes, it is way too easy to do
the wrong thing in more complicated scenarios than what your examples