On 2014-08-01 18:46, Eric Niebler wrote:

Then you can use it like a constexpr Boolean function in enable_if, which can be conveniently wrapped in a simple macro like:

template void advance(I i, iterator_difference_t<I> n) { // ... } Really nice! But won't work with variadic templates, would it? Since I cannot do something like

template())> Cheers, Roland

On 2014-08-02 23:32, pfultz2 wrote:

...

Really nice! But won't work with variadic templates, would it? Since I cannot do something like

template())> It will work for functions. Not for classes though. Could you post an example? Is the concept check done in the return type as with enable_if?

On 2014-08-03 15:56, pfultz2 wrote:

...

Could you post an example? Is the concept check done in the return type as with enable_if? In C++11, we can use a default template parameter, rather than the return type, which is what the `CONCEPT_REQUIRES_` uses. So for example, we can write:

template())> auto foo(T&&... xs) { ... }

This works as long as all the varidiac template types are to be deduced by the compiler.

Thanks for the explanation. Good to know!

For classes this won't work:

// ERROR template())> struct foo { ... };

Because you can't have a default template parameter after the varidiac template parameters in this context(you can when using speczializations).

Of course, you can't use `CONCEPT_REQUIRES_` for class specialization. In my library, I do provide a `TICK_CLASS_REQUIRES` which can be used for class specializations. Note that since it relies on `enable_if` it won't resolve ambiguities like Concepts Lite will. For example:

template<typename T> struct foo;

template<typename T> struct foo())> { ... }; // Here we have to add a check for `RandomAccessIterator` to avoid ambiguities template<typename T> struct foo() && !RandomAccessIterator<T>())> { ... };

Perhaps, there is a way to this using tag dispatching, I'm not sure.

Thanks and regards, Roland

I'm trying to promote the simplest view of "type constraints" which can possible work. Your solution does more - at the cost of requiring a lot more effort to understand and use correctly. (there is no documentation about it either). Then there is the fact that it requires a compiler "man enough" (hmmm - why not woman enough?) to use. So I don't think it's a good vehicle for promoting the concept of type constraints.

I don't think Eric's solution requires more to understand than using Boost.ConceptCheck, unless you want to do more such as overloading. Also, my library version of the this does have documentation and has been tested and works on gcc 4.6/4.7/4.8/4.9 and clang 3.4(I do plan to submit a boostified version soon).

I would just like every library invoke a compile time assert whenever in instantiate a template with type arguments which won't work. Boost Concept Check can do this. In fact, maybe BCC is over kill. I seriously considered recommending making concept checking classes with just static_assert. But in the end I opted for recommending BCC.

Yes, of course, static assertions can help improve error messages and its better than nothing, but it is not the same as template constraints. This will become more obvious as more people start using concept predicates. Ideally, if a library is targeting C++11 they could perhaps use concept traits rather than Boost.ConceptCheck. -- 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.

On 3/08/2014 5:58 PM, Roland Bock wrote:

namespace detail { template struct wrong { using type = std::false_type; }; } template using wrong_t = typename detail::wrong::type;

It can be used to defer static_assert until a template is instantiated which is an error since it is prohibited:

// disabled default case, slightly shortened from [2]

template struct serializer_t { static_assert(wrong_t::value, "missing serializer specialization"); };

I saw this in your "template toffees" talk and I wondered then whether it wouldn't be simpler to do this: template struct serializer_t { static_assert(deferred_false, "missing serializer specialization"); }; --- Michael

b) You have one or more full or partial class specializations for specific classes/templates/values:

Basically as above, but if you want to prohibited the default case or certain specializations, here's a nice, minimalistic helper to do so

This is a perfect example of when *not* to use static_assert. You should leave the class undefined: template struct serializer_t; Then the compiler will already give a simple and informative error about the class being undefined, which is almost the same error you put in the static_assert. Futhermore, say I want to know if there is a valid serializer at compile-time and if not then choose a different method. So, I create a predicate to detect a valid serializer: TICK_TRAIT(has_serializer) { template auto requires_(Context ctx, const T& x) -> decltype( has_type(), Context::_(x, ctx) ); }; Unfortunately, this won't work because of the hard error, and it won't work with Concepts Lite either. `static_assert` can be used to check variants outside of type requirements, but in general, it should not be used for type requirements. -- 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.

Roland Bock-2 wrote

On 2014-08-02 23:57, pfultz2 wrote:

...

...

I would just like every library invoke a compile time assert whenever

...

in instantiate a template with type arguments which won't work. Boost Concept Check can do this. In fact, maybe BCC is over kill. I seriously considered recommending making concept checking classes with just static_assert. But in the end I opted for recommending BCC. Yes, of course, static assertions can help improve error messages and its better than nothing, but it is not the same as template constraints. True, but static_assert covers the following cases at least and is really simple:

a) You have one implementation (class or function) and arguments are either valid or not:

template<...> struct X { static_assert(check1, "failed check1"); ... };

b) You have one or more full or partial class specializations for specific classes/templates/values:

Basically as above, but if you want to prohibited the default case or certain specializations, here's a nice, minimalistic helper to do so [1]:

namespace detail { template struct wrong { using type = std::false_type; }; } template using wrong_t = typename detail::wrong ::type;

It can be used to defer static_assert until a template is instantiated which is an error since it is prohibited:

// disabled default case, slightly shortened from [2] template struct serializer_t { static_assert(wrong_t ::value, "missing serializer specialization"); };

// Any number of valid specializations like this [3] template struct serializer_t<Context, column_t<Args...>> { // You could have static asserts here, too };

// Or you can switch off certain cases [4]: template<typename Lhs, typename Rhs, typename On> struct serializer_t<sqlite3::serializer_t, join_t<outer_join_t, Lhs, Rhs, On>> { static_assert(::sqlpp::wrong_t ::value, "No support for outer join"); };

static_assert is not sufficient for selecting overloads or if you have several class specializations and need to select the correct one based on concepts like ForwardIterator or so. In those cases, I would use enable_if or similar (and wait for Concepts Lite).

In the sqlpp11 code, which enforces type constraints in pretty much every template, enable_if is required in only about 7% of the templates. Most of them are implementations of the constraint-checks.

Regards,

Roland

[1]: https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/wrong.h [2]: https://github.com/rbock/sqlpp11/blob/develop/include/sqlpp11/serializer.h [3]: https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/column.h [4]: https://github.com/rbock/sqlpp11-connector-sqlite3/blob/develop/include/sqlp...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

I see using static_assert as a real practical method for many users. But just saying one can use static_assert to implement type constraints is not quite the same as showing users how to do it. I would encourage you go to enhance http://rrsd.com/blincubator.com/advice_concepts/ with this information. You an either post a comment or send it directly to me. My real goal is to convince the C++ community that any library which includes templates as part of the user interface must have explicit type constraints in order to be considered for formal review. I want to see type constraints be understood and appreciated by the C++ user community in general rather than a small group who spend years disputing how to implement the idea. Let's start making things better right now! Robert Ramey -- 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.

On 3 Aug 2014 at 8:48, Robert Ramey wrote:

My real goal is to convince the C++ community that any library which includes templates as part of the user interface must have explicit type constraints in order to be considered for formal review. I want to see type constraints be understood and appreciated by the C++ user community in general rather than a small group who spend years disputing how to implement the idea.

I strongly disagree with this idea if by "type constraints" you mean "error out if it doesn't fit" which apparently you do. That isn't really concepts at all in my opinion, it's just some sort of super static assert. We are still in the very early days of concepts, language support isn't even in there yet - it is like trying to standardise exception handling before the language gained support. Once the TS is finished and accepted and we know exactly what will be in the language, then is the time to start thinking about formal review requirements. i.e. at least two or three years from now. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 2014-08-03 22:16, Niall Douglas wrote:

On 3 Aug 2014 at 8:48, Robert Ramey wrote:

...

My real goal is to convince the C++ community that any library which includes templates as part of the user interface must have explicit type constraints in order to be considered for formal review. I want to see type constraints be understood and appreciated by the C++ user community in general rather than a small group who spend years disputing how to implement the idea. I strongly disagree with this idea if by "type constraints" you mean "error out if it doesn't fit" which apparently you do. Hmm? If the arguments do not fit, an error is required. The kind of error is debatable. As Paul points out, a hard error like static_assert is too strong if you want to use it with SFINAE.

But there has to be an error of some kind if the arguments don't fit.

That isn't really concepts at all in my opinion, it's just some sort of super static assert. It really depends on the kind of error you produce. Afaict Concepts Lite will create SFINAE-compatible errors.

Cheers, Roland

On 31 Jul 2014 at 10:11, Eric Niebler wrote:

On 07/29/2014 05:14 PM, Niall Douglas wrote:

...

I'm all for Concepts as in compiler enforced ones, and I'll add them to AFIO when and only when C++ gets them. But for documentation they don't help.

Wow, I couldn't disagree more. I can't imagine how the standard algorithms would be specified without the use of concepts like "RandomAccessIterator", for instance. Clustering requirements into meaningful abstractions and assigning them names makes it possible to document library interfaces without an explosion of verbosity and repetition.

Oh I know programmers similar to how you visualise code in your head would agree with you absolutely. But you must remember programmers like me don't see C++ as really in fact having types nor classes nor concepts - I just see methods of programming the compiler to output patterns of assembler code, and I think primarily in terms of chains of assembler instructions. My type of programmer learns just enough of the verbiage to understand C++ Now presentations by programmers such as you (and I haven't failed to learn something new from yours yet), but we'll never think like you any more than you'll think like us. None of this a bad thing of course, diversity of approach and all. But to me and people like me a RandomAccessIterator is a pointer and is little different to a ForwardIterator. I care about the difference only in so far as I can use it to get the compiler to generate code one way or another according to need. I furthermore care about the difference only in so far as it will get later maintainers and team members to behave one way instead of another. Past that I feel no issue reinterpret casting STL internal types to bypass the type system if that gets me the assembler output I want and doesn't create maintenance debt later. It's the essential difference between language-focused coders and err ... mongrel coders? I have to admit I'm not sure what to call myself really. Either way, I see ConceptCheck as a half baked feature giving me nothing useful but bloat and complexity and significantly adding mess to documentation and steepening my learning curve. I absolutely can't wait for language support for Concepts, and will use them with vengence when they turn up as they're another great tool for bending the compiler in new ways, but until it's fully baked as a language feature they get in my way. And hence I don't use them personally, and groan every time I'm faced with code by someone who has (no offence intended here, we all have our own personal likes and dislikes, and I entirely understand your opinions on this and respect them, I just don't have those opinions myself). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

I'm a bit worried that: - Hana exposes a C++1y library-based implementation of concepts on its interface (typeclasses). Would moving it to concepts (once we get language-support in 2015/16) introduce a big breaking change? Then, Range-v3, TICK, Hana, and others are all using _different_ C++11/1y library-based implementations of concept checking which I guess means that: - there is need for such a library, and - Boost.ConceptCheck is for whatever reason not good enough in C++11/1y world yet. On Fri, Aug 1, 2014 at 2:26 AM, Edward Diener wrote:

On 7/31/2014 6:28 PM, Niall Douglas wrote:

...

On 31 Jul 2014 at 10:11, Eric Niebler wrote:

On 07/29/2014 05:14 PM, Niall Douglas wrote:

...

...

I'm all for Concepts as in compiler enforced ones, and I'll add them to AFIO when and only when C++ gets them. But for documentation they don't help.

Wow, I couldn't disagree more. I can't imagine how the standard algorithms would be specified without the use of concepts like "RandomAccessIterator", for instance. Clustering requirements into meaningful abstractions and assigning them names makes it possible to document library interfaces without an explosion of verbosity and repetition.

Oh I know programmers similar to how you visualise code in your head would agree with you absolutely. But you must remember programmers like me don't see C++ as really in fact having types nor classes nor concepts - I just see methods of programming the compiler to output patterns of assembler code, and I think primarily in terms of chains of assembler instructions. My type of programmer learns just enough of the verbiage to understand C++ Now presentations by programmers such as you (and I haven't failed to learn something new from yours yet), but we'll never think like you any more than you'll think like us.

None of this a bad thing of course, diversity of approach and all. But to me and people like me a RandomAccessIterator is a pointer and is little different to a ForwardIterator. I care about the difference only in so far as I can use it to get the compiler to generate code one way or another according to need. I furthermore care about the difference only in so far as it will get later maintainers and team members to behave one way instead of another. Past that I feel no issue reinterpret casting STL internal types to bypass the type system if that gets me the assembler output I want and doesn't create maintenance debt later.

It's the essential difference between language-focused coders and err ... mongrel coders? I have to admit I'm not sure what to call myself really. Either way, I see ConceptCheck as a half baked feature giving me nothing useful but bloat and complexity and significantly adding mess to documentation and steepening my learning curve. I absolutely can't wait for language support for Concepts, and will use them with vengence when they turn up as they're another great tool for bending the compiler in new ways, but until it's fully baked as a language feature they get in my way. And hence I don't use them personally, and groan every time I'm faced with code by someone who has (no offence intended here, we all have our own personal likes and dislikes, and I entirely understand your opinions on this and respect them, I just don't have those opinions myself).

With all due respect to your super-practical low-level approach I think you must know that you are very much in the minority. Practical programming, as you reflect on above, certainly has its advantages but without knowing what one can do with a programming language I see it as impossible to design robust code that is both understandable and usable to others and effective in accomplishing its goal.

I do not think 'concepts', aka largely 'type constraints' as Robert as aptly renamed it in this discussion, is a panacea for every template programming problem. But understanding the 'domain' of what a 'type' entails is just as important as understanding the 'domain' of some parameter in a function call. Without documentation of such things the user of your constructs has no idea what will work and what will not work and programming then becomes and endlessly wasteful game of trial and error.

Nor is that really 'language-focused' programming. Its just programming that takes into account that others must usually be able to use what you create else it is worthwhile only to yourself and your own solution to a problem.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

I'm a bit worried that: - Hana exposes a C++1y library-based implementation of concepts on its interface (typeclasses). Would moving it to concepts (once we get language-support in 2015/16) introduce a big breaking change?

Concepts are not being added in the near future to C++. Concepts lite is proposed to add concept predicates to C++, which is very different.

Then, Range-v3, TICK, Hana, and others are all using _different_ C++11/1y library-based implementations of concept checking which I guess means that: - there is need for such a library, and - Boost.ConceptCheck is for whatever reason not good enough in C++11/1y world yet.

Hana does implement a form of concepts in C++. The Tick library only implements a form of concept predicates, which was based on what is done in the Range-V3. Of course, it might make sense to make Hana's typeclass a separate library(although it should be called 'concepts' instead). Of course, Boost.ConceptCheck is only good for improving error messages. It is very inadequate, and can be very problematic when combined with concept predicates. -- 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.

On 31 Jul 2014 at 20:26, Edward Diener wrote:

...

...

On 07/29/2014 05:14 PM, Niall Douglas wrote:

...

I'm all for Concepts as in compiler enforced ones, and I'll add them to AFIO when and only when C++ gets them. But for documentation they don't help.

Wow, I couldn't disagree more. I can't imagine how the standard algorithms would be specified without the use of concepts like "RandomAccessIterator", for instance. Clustering requirements into meaningful abstractions and assigning them names makes it possible to document library interfaces without an explosion of verbosity and repetition.

Oh I know programmers similar to how you visualise code in your head would agree with you absolutely. But you must remember programmers like me don't see C++ as really in fact having types nor classes nor concepts - I just see methods of programming the compiler to output patterns of assembler code, and I think primarily in terms of chains of assembler instructions. [snip] It's the essential difference between language-focused coders and err ... mongrel coders? I have to admit I'm not sure what to call myself really. Either way, I see ConceptCheck as a half baked feature giving me nothing useful but bloat and complexity and significantly adding mess to documentation and steepening my learning curve.

With all due respect to your super-practical low-level approach I think you must know that you are very much in the minority. Practical programming, as you reflect on above, certainly has its advantages but without knowing what one can do with a programming language I see it as impossible to design robust code that is both understandable and usable to others and effective in accomplishing its goal.

Practical programming isn't the right term ... I'm going to borrow a term Artur Laksberg used during my interview at Microsoft, let's call it "data flow centric programming". At scale, those patterns of assembler outputs start to look like stretchy sheets, and they come together to form a sort of hills and valleys. You could say that each CPU core is rather like a river trying to follow a path of least resistance amongst that topology, and our job as programmer is to apply transformations to the topology to yield new flows of river. It is rare that applying any transformation isn't a zero-sum outcome, and that is where skill and experience comes in. When visualised in that way, there is no essential difference between programming languages, or operating systems, or the humans working on those systems. They're all programmed the same way. Advantages include agnosticism towards languages, OSs, idelogies ... disadvantages include inability to relate, communicate or otherwise transmit meaning to other engineers, except those of a similar bent. Most engineers accept the difference as a good thing adding an uncertain value, but the occasional one feels it as a vital threat that must be destroyed at all costs, which is unfortunate. That can introduce politics into engineering, which is usually a bad thing.

I do not think 'concepts', aka largely 'type constraints' as Robert as aptly renamed it in this discussion, is a panacea for every template programming problem. But understanding the 'domain' of what a 'type' entails is just as important as understanding the 'domain' of some parameter in a function call. Without documentation of such things the user of your constructs has no idea what will work and what will not work and programming then becomes and endlessly wasteful game of trial and error.

Nor is that really 'language-focused' programming. Its just programming that takes into account that others must usually be able to use what you create else it is worthwhile only to yourself and your own solution to a problem.

You're making the enormous assumption that all worthwhile programmers think like you and have the same value sets you do e.g. that domains have any relevance to parameter types at all, or that outstanding quality code cannot be written without a language-based approach. One of my biggest problems with Boost code and its documentation (and the C++ 11/14 STL additions) is that meaning as well as implementation is scattered all over the place in fragments. Languagey type programmers grok that much easier than I or most on StackOverflow do, probably because they instantly spot the nouns and the verbs and type systems are natural to them. Me personally, I'm old fashioned and I'd like my API documentation to tell me what the API actually does and how it fits with other APIs like a man page does rather than a single line comment and many hyperlinks to all the semi-concept types being input and output. I also want to see an essay at the beginning on the philosophy of the design (what I normally call a design rationale), because that will tell me how it all is intended to hang together. After all, as a result of the lack of direct language support there are many Concept check designs, each incommensurate with the others, hell even the STL itself has at least two if not three separate ways of Concept checking, none of which are fully baked either. In truth, despite your assertion of me being in a minority, I suspect my sort of programmer is probably the majority in C++ if not in Boost. If you want a pure or elegant type system you wouldn't choose C++ for example - in fact, if you cross off the list of reasons, the only reasons that *anyone* would intentionally choose C++ is down to (i) potential bare metal performance and (ii) it is also C which is useful for low level work and (iii) the tools and ecosystem are mature. That ought to bias against languagey type programmers, though for obvious reasons the best of the field whom I would assume would like to congregate here or on ISO are much more likely to be languagey type programmers as they are interested in C++ as a language. One of my great hopes for Hana and why I am so excited by it is that we might finally get a reasonably good standardised way of doing abstract base templates for template classes. Concept check implementations have tended to use class inheritance in the past due to lack of language support to do otherwise, while libraries such as Fusion have used a ton of hand written metaprogramming which makes them very slow and brittle. Hana has been written to be fast which solves my first objection to using Fusion in any production code, the enormous question still remaining is how brittle or not it will be to use in real world code. Can I use Hana to stamp out entire families of STL iterator so I no longer have to write my own for example? Will it be easy for me to adjust entire families of STL iterator both from the top, in the middle and the bottom without tons of compiler error spew? Will the users of my iterator never notice that I used Hana underneath? Those are open questions of course, and it will be some years before I can use Hana in any code expected to be portable sadly :( Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 3 Aug 2014 at 12:58, Rob Stewart wrote:

...

...

...

Oh I know programmers similar to how you visualise code in your head would agree with you absolutely. But you must remember programmers like me don't see C++ as really in fact having types nor classes nor concepts - I just see methods of programming the compiler to output patterns of assembler code, and I think primarily in terms of chains of assembler instructions.

I have to assume you're using hyperbole to make your point.

I did make use of argumentum ad absurdum as otherwise no one would notice what I just said. People already filter out 75% of what you write, forcing you to repeat everything you say thrice. As I earn hourly, I can't afford that, writing email literally costs me money.

C++ has types and it has classes, so I can't believe you perceive it otherwise. OTOH, I can imagine that you see those things merely as levers and knobs to produce the desired machine code.

You actually took the words out of my mouth - yes, levers and knobs is a good example, or a superior assembler macro implementation is a better one.

...

...

...

[snip] It's the essential difference between language-focused coders and err ... mongrel coders? I have to admit I'm not sure what to call myself really.

You use abstractions whenever you discuss real world objects. In fact, you use them in any natural language conversation. I'm sure you use them in programming conversations, too. Consequently, I think you're overstating your case.

I clarified what I meant in a subsequent email, but I was trying to explain that there are two big classes of programmer, one who thinks in terms of language and symbols and grammar, and the other who thinks in terms of stretchy sheets. That's also an argumentum ad absurdum, there are certainly more than just two classes, but hopefully you get what I mean.

...

...

...

Either way, I see ConceptCheck as a half baked feature giving me nothing useful but bloat and complexity and significantly adding mess to documentation and steepening my learning curve.

Concepts are so much noise in introductory documentation. However, for detailed and reference docs, they are indispensable to avoid repetition and to reveal similarities and differences among the types on offer by a library. I wonder if your complaint is more about their use on specific cases than about them on general.

You make a *very* valid point here. My biggest complaint is how they are used as an excuse for bad documentation, you are absolutely right on the button on that. My second, and much more minor complaint is they can make code more brittle than it should be because I don't think class inheritance nor SFINAE is the right way to implement policy/trait/concepts when improved language support is the only right way there, but that doesn't bother me anything like as much because I can simply go use an alternative library.

...

Practical programming isn't the right term ... I'm going to borrow a term Artur Laksberg used during my interview at Microsoft, let's call it "data flow centric programming". At scale, those patterns of assembler outputs start to look like stretchy sheets, and they come together to form a sort of hills and valleys. You could say that each CPU core is rather like a river trying to follow a path of least resistance amongst that topology, and our job as programmer is to apply transformations to the topology to yield new flows of river. It is rare that applying any transformation isn't a zero-sum outcome, and that is where skill and experience comes in.

When visualised in that way, there is no essential difference between programming languages, or operating systems, or the humans working on those systems. They're all programmed the same way.

Advantages include agnosticism towards languages, OSs, idelogies ... disadvantages include inability to relate, communicate or otherwise transmit meaning to other engineers, except those of a similar bent.

Your view of programming languages and libraries as means to an end doesn't mean you don't have to know the languages and libraries you happen to use. Documentation use natural and programming languages to convert information. Human communication uses abstractions for efficiency. Good abstractions are helpful, even to someone like you, aren't they?

Of course. I just used a ton of similes to explain myself above which are the essence of abstraction. Abstraction basically *is* computer programming, perhaps even more so than maths. What I was trying to convey was that some programmers get upset by the ugliness of breaking the purity of the type system, and it innately bothers them. I, on the other hand, have no problem with the monstrosity at https://github.com/ned14/nedtries/blob/master/nedtrie.h#L1853 which I would imagine would appall any right minded C++ person here (for those curious, it's a generic STL container wrapper which subverts that container to become a bitwise trie indexed container. The code is spectacularly evil, and includes casting references through intermediate placeholder types and back into their originals and lots of other similar fun. Note that I explicitly warn people in the documentation not to use it). This is the difference I mean. Language/symbols/grammar programmers get upset at people using reinterpret_cast *at* *all* because it's seen like goto, a taboo. Me well I don't care about that, or goto either which I do use from time to time (it's sometimes the best solution available). What gets compilers to jump right in a maintainable way is all that matters to me (note I don't view the nedtries monstrosity as being maintainable, it was supposed to be a one-shot effort, I was quite mistaken on the popularity of that code sadly).

...

Most engineers accept the difference as a good thing adding an uncertain value, but the occasional one feels it as a vital threat that must be destroyed at all costs, which is unfortunate. That can introduce politics into engineering, which is usually a bad thing.

Differences are often beneficial. They can also be a source of friction. However, to my knowledge, I've never before encountered anyone with your view of programming in over 30 years of programming who wasn't using assembler.

Well ... I still think of myself as primarily an assembler programmer, but I learned to not say so on my resume quite early on. I learned to program in 6502, moved into ARM, then adopted C as a more powerful macro programmer with the added benefit of being portable. That naturally evolved into C++ as an even more powerful macro engine and metaprogramming as even more powerful again, and I still debug mostly using the disassembly view which is why I still like Visual Studio so much (it has a much better disassembly based debugger than Eclipse). That way of seeing things is of course how a compiler writer sees things, and I found porting clang to QNX in my spare time whilst at BlackBerry effortless which some others thought too good to be possible or feasible or indeed wise. This doesn't mean I can't write in other languages, which I'd call "interpreter" and includes BBC Basic, Python, Javascript, XSLT etc. They all have interpreter dynamics i.e. avoid creating and destroying things and you've probably got high performance. In 2011 as part of creating a cloudy Web 2.0 startup I wrote the main product in a combination of Python, C#, Javascript and Java, all of which was surprisingly quick and was far above the performance needed. If anything, in hindsight, I should have taken more shortcuts actually.

...

You're making the enormous assumption that all worthwhile programmers think like you and have the same value sets you do e.g. that domains have any relevance to parameter types at all, or that outstanding quality code cannot be written without a language-based approach.

I suspect, like me, he's never encountered someone like you. While the specific does not the general make, it certainly informs one's views.

Many read my repeated posts here over these past eighteen months and have asked me personally why I bother. Your reply is why I do. It is still worth writing back here. Also, I would not have my current employment if it were not for those who read this mailing list and thought something of my posts, and I am extremely grateful for that.

I'm not sure where I fit in your taxonomy, but I dislike Boost.Filesystem's documentation because Beman wrote it as if it was to be submitted for inclusion in the Standard, while providing little other information. I read the Standards, and I can extract beneficial information from them without a lot of difficulty, but it isn't helpful when trying to learn about something for the first time.

I do see what you mean. However Filesystem is a very thin abstraction over POSIX. It contains few surprises, apart from the occasional bug. That significantly reduces my demand of its documentation - almost all of it can suffice with a single line and a few usage examples. Where Filesystem seriously falls down in my opinion is its lack of API guarantees. For example, a big bugbear of mine is what are its guarantees of metadata consistency on a filesystem experiencing rapid change? If I read metadata about a file, and during the (let's say) five API calls used to read metadata that metadata changes, you end up with inconsistent metadata. I want the relevant APIs to state how consistent they are on various operating systems. For example, POSIX lets us have stat which is atomic and all major POSIX implementation also provide a limited atomic directory enumeration API. Win32 provides lots of itty bitty calls which are not atomic, but going direct to the NT kernel gives you not just stat but a whole load of extra lovely stuff like you can atomically fetch the stat for all files matching a glob pattern in a directory. I have tried to raise this with Beman before, but seen nothing about it. This sort of stuff affects how useful Filesystem is in the real world. Without guarantees Filesystem is not useful for database code etc.

...

I also want to see an essay at the beginning on the philosophy of the design (what I normally call a design rationale), because that will tell me how it all is intended to hang together.

As do I.

...

After all, as a result of the lack of direct language support there are many Concept check designs, each incommensurate with the others, hell even the STL itself has at least two if not three separate ways of Concept checking, none of which are fully baked either.

Flawed concept checking does not negate the value of concepts for the documentation. It just makes them less helpful at compile time.

Ok, if you can deliver me documentation where the concept documentation appears at every point of use in a non-obtrusive way (let's say a wee '+' you can expand or hover over or something), I'll retract any objection I have to the use of concept checks in other people's code. You may need to give me a while to come around with my own code, but I think you're right earlier on, my single biggest objection is the laziness it introduces into documentation.

...

In truth, despite your assertion of me being in a minority, I suspect my sort of programmer is probably the majority in C++ if not in Boost.

Setting aside your view of languages as the means to the end of bits flowing over a landscape, I agree.

FYI Artur Laksberg in Microsoft has a similar view to my own on flows of data. We talked about our similarity of vision at the pub during my interview there :)

...

If you want a pure or elegant type system you wouldn't choose C++ for example - in fact, if you cross off the list of reasons, the only reasons that *anyone* would intentionally choose C++ is down to (i) potential bare metal performance and (ii) it is also C which is useful for low level work and (iii) the tools and ecosystem are mature. That ought to bias against languagey type programmers, though

That's a misguided view. I choose C++ because it's multiparadigm. It provides low level tools, OO, meta-programming, etc.

I can agree with that statement too.

...

for obvious reasons the best of the field whom I would assume would like to congregate here or on ISO are much more likely to be languagey type programmers as they are interested in C++ as a language.

I'm interested in improving my and other's ability to use C++ effectively.

And fittingly, we end on absolute agreement with one another. It's one of the reasons I volunteered to act as Boost GSoC admin, to help in getting more young blood in here which is sorely needed. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Awesome library! Here are some of my thoughts on the library. It seems like you are bringing haskell to C++. However, in the past, functional libraies seem to struggle with acceptance in boost. It seems like it would be nicer to name and organize things in a way that is familiar to C++ programmers. One of the things that helped make it easy for me when I firsted learned Boost.MPL, was it was built around the STL interface. I understand in Boost.Hana, you don't use iterators for performance, but it still could be organized in a way that is more familiar to C++ programmers(Some places I've worked, there was resistance to even using Boost.Fusion, which is built around familiar C++ interfaces. Imagine if I tried to introduce Boost.Hana.) Here's a few list of names off the top of my head that could use more C++-like names: foldl = fold foldr = reverse_fold fmap = transform cons = push_front scons = push_back datatype = tag,tag_of head = front last = back typeclass = concept Also, most C++ programmers are used to seeing libraries divided into containers and algorithms, whereas Boost.Hana seemed to be built around haskell-like interfaces. As C++ programmers, its difficult to find where to look for functionality. Ideally, it would be nice to start with simple concepts, such as iteration, and then have algorithms built on top of that. And then have a mechanism to overload algorithms to improve the performance for certain sequences(for example `mpl::vector` algorithms could be specialized to improve compile time performance). It seems like you can overload the algorithms in your library, but its spread across different typeclasses. And then the `List` typeclass has a bunch of algorithms in them. Since, `List` is heavy, I can't split the specializations of these algorithms across several header files, for example. It would be better to have smaller and simpler concepts. However, the specializations of these concepts should be for advance use of the libraries. It should start with some simple concepts to get people to start using the library, and then if someone wants to create an optimized `reverse_fold`, they could. It would be nice to see the docs divide into something like: - The basic type concepts(such as `type<>`, integral constants, metafunctionn, etc) - The basic sequence concepts, what concepts are necessary to define a hana sequence, and the different sequences - Accessing data from a hana sequence, such as `at`, `front`, `back` - Views or adaptors on sequences, such as filter, transform - Algorithms on sequences, such as `fold`, `max`, etc - Extending Boost.Hana Those are some thoughts after reading through the library. Perhaps, I missed some design goals you have. -- 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.

On Wed, Jul 30, 2014 at 1:19 AM, Louis Dionne wrote:

pfultz2 writes:

...

Here's a few list of names off the top of my head that could use more C++-like names:

foldl = fold foldr = reverse_fold fmap = transform cons = push_front scons = push_back datatype = tag,tag_of head = front last = back typeclass = concept

I agree that using more C++ish names could make it more tempting for people to adopt the library. I'll think about providing aliases.

I agree with Paul, for FWIW. (as an average C++ dev who only dabbled in MPL and Fusion, with little FP experience, and who finds cons and scons really "esoteric")

...

Also, most C++ programmers are used to seeing libraries divided into containers and algorithms, whereas Boost.Hana seemed to be built around haskell-like interfaces.

Hana is actually built around concepts (type classes) and models of those concepts (data types). Apart from the names, which I agree could have been chosen differently, it's the same "design paradigm" as usual generic C++ libraries.

Names matter of course. And the closer you stay to C++ lore, as Paul mentioned, the better IMHO. And I'm not sure aliases is the way to go, since having two names for the same thing only makes code reading difficult if it uses the "other" name one's not used to. It's your library of course, I'd never -1 it based on the name you prefer to use. Thanks, --DD

On 7/30/2014 9:10 AM, pfultz2 wrote:

On 7/29/2014 4:19 PM, Louis Dionne wrote:

...

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. \e

pfultz2 writes:

...

That is slightly inacurate. I don't use iterators because other abstractions provide much more expressiveness and are much more general than iterators. Since performance is not an argument in favor of iterators in our case (as you rightly observe), they are not used. The #1 reason is expressiveness.

I understand how it is simpler to define sequences using `head`/`tail`, but how is it more expressive?

Of course it's not more expressive in a formal way because you can achieve the same things with both. I was speaking about the generality of Hana type classes, e.g. instead of having iterator categories I have Functor, Foldable, Iterable and Traversable. These are more general concepts and they can be used more widely than iterators. For example, Maybe is like a compile-time std::optional. It is easy to make it a Functor, but it would seem wrong to try and define an iterator over a Maybe. Not that it can't be done, just that it feels wrong.

...

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

I was speaking in the context of metaprogramming. Whether iterators are suited for this or that in another context is a different debate I'm neither qualified nor willing to have.

...

I did try using both.

What limitiation did you run into seperating "Sequences" and "Algorithms"?

I said Sequences and Containers, not Sequences and Algorithms. Splitting sequences and algorithms is fine, and that's what's done in Hana. Related algorithms are bundled into type classes and sequences (or more generally data types) must define a fixed set of primitives to be usable with those algorithms. When I first started working on the MPL11, I took all the concepts from the MPL and tried to split it so it would work without iterators. That's when I ran into problems. I don't remember the specifics because that was a while ago, but I could look into my old notes if you really want details.

[...]

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.

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.

Also, the uses concepts that have a default methods are not very common. In general, a C++ concept defines a core set of functionality that can be used to extend a library.

...

...

Ideally, it would be nice to start with simple concepts, such as iteration, and then have algorithms built on top of that.

I'm not sure what you mean by that. Do you mean change the structure of type classes, or how they are introduced?

Yes, change the structure of the typeclasses. For example, `Iterable` has `for_each` included(which is defaulted). However, you could seperate `for_each` out as an algorithm that requires an `Iterable`. Then have a seperate mechanism to override the algorithms, such as for varidiac templates:

template class Sequence, class... Ts> struct algorithm> { template<class F> static void call(Sequence & s, F f) { ... } };

The same can be done for the accessors as well in the `Iterable` typeclass.

I could rip out all methods except their minimal complete definition from every type class, and have those other methods be "algorithms that require instances of the type class". However, you can now only have a single minimal complete definition for each type class, which is less flexible. Let's pretend that you can somehow have multiple MCDs. Now, the default definition of the algorithms that were ripped out can't depend on that MCD, because they are out of the type class. That's another loss of flexibility. All in all, I see no gains and only losses in ripping out methods from the type classes. You seem to be asking for flexibility. I designed every single bit of the type class dispatching system so 1. Every single algorithm can be overriden provided you instantiate the type class. 2. You always get the maximum number of algorithms for as few definitions as possible. 3. You do not _ever_ have to duplicate the definition of an algorithm. 4. Depending on the basis operations you provide when instantiating a type class, it is possible that the defaults will be more or less performant. If you can explain to me what your proposal allows that can't be done right now, I'm open for discussion. That being said, and based on your specific example for variadic templates, I think you're wondering why there are no efficient operations for variadic sequences. It's because I haven't had the time to add it, but here's what's planned: // Minimal complete definition: unpack struct Foldable::unpack_mcd { // Now, I can implement foldr, foldl, sum and whatnot _super_ // efficiently, and any sequence-like thing that can unpack its // content into a variadic function is qualified to get it. };

...

There are two things here. First, the decision not to split the library into a thousand headers was considered a feature, because it meant that you did not need to include countless headers to get some functionality. Since the library is very lightweight, it does not cause a compile-time performance problem to include the whole list.hpp header.

Even so, in your implementation of list.hpp, it may not be performance hit to include it together, but perhaps as a user, I could be adapting a type where each of those methods are heavyweight, so I would want to seperate them out into seperate headers.

Ahhh, now I understand what you mean. I think that's possible and I'll reply when I'm fixed. Basically, I'll try to split the adaptor for Fusion into separate header and see if it works.

...

Second, I agree that the List type class is heavy, but that's because it's more like a data type really. The only reason I made it a type class is because I wanted to give `fusion::vector`, `std::tuple` and friends the same methods as `hana::list`, for free. The laws of List force every instance to be isomorphic to `hana::list`, so there is no reason why you would want to instantiate it.

Just as non-member functions are preferred when they only access public members, I believe this same advice can be applied here. Each method that has a default implementation could be made as a seperate function(which could be designed to be overloaded as well).

I really don't think the same advice can be applied here, and I don't see why it should. Type classes and regular structs are conceptually very different entities, even if they are implemented in the same way. Louis

I could rip out all methods except their minimal complete definition from every type class, and have those other methods be "algorithms that require instances of the type class". However, you can now only have a single minimal complete definition for each type class, which is less flexible. Let's pretend that you can somehow have multiple MCDs. Now, the default definition of the algorithms that were ripped out can't depend on that MCD, because they are out of the type class. That's another loss of flexibility. All in all, I see no gains and only losses in ripping out methods from the type classes.

Of course, you don't have to rip out every default method. It makes sense to keep some when you have multiple MCDs.

If you can explain to me what your proposal allows that can't be done right now, I'm open for discussion.

Of course, you can achieve that already in your library, but what I'm proposing is to separate the two purposes you have for implementing typeclasses. Instead, the user would implement a typeclass to fulfill type requirements, and would overload an algorithm to provide optimizations.

I really don't think the same advice can be applied here, and I don't see why it should. Type classes and regular structs are conceptually very different entities, even if they are implemented in the same way.

Perhaps, the advice doesn't directly apply. However, bloated typeclasses seems to be bad design. C++ concepts are never bloated like this nor are haskell typeclasses.

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.

The definition of a monad from wikipedia is a structure that represents computations defined as sequences of steps, so calling it `Computation` makes sense. Also the definition and the name is simple and clear to a lot of non-FP programmers. In contrast, calling it a monad and then defining it as an applicative with the ability to flatten values that were lifted more than once, is pretty meaningless to most C++ programmers. Monads as computations is just one metaphor, but it is the metaphor most familiar to C++ programmers. Or do you think there is a better metaphor for C++ programmers? Here are some other thoughts after looking at it more: - A lot of functions can be implemented with just `Iterable`, such as fmap, concat, cons, filter, init, take, take_while, take_until, etc. Or am I missing something? - The parameters to the functions are backwards to what most C++ programmers are used to, which will be the source of unendless confusion. I assume they are in this order because of its usefulness for curring inside applicatives. Perhaps instead, you could have another function adapter that rotates the first parameter to the last parameter, and then still keep the C++ convention of putting the sequence first. - It's important to note that the `decltype_` function will only work for constexpr-friendly types. - There seems to be a lot of copying by value, where it should use perfect forwarding. Has this been tested with non-copyable types and expensive to copy types as well? -- 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.

If the methods are separated from the type classes, they can't have a default definition which depends on the MCD that's used. For example, let's pretend I have two MCDs for Foldable; `fold_mcd` and `unpack_mcd`. `fold_mcd` requires both `foldl` and `foldr`, and `unpack_mcd` requires `unpack`. Now, there are multiple ways to implement `sum`. Two of them are:

auto sum = [](auto xs) { return foldl(_+_, int_<0>, xs); };

auto sum = [](auto xs) { return unpack(some_very_fast_sum_on_variadic_packs, xs); };

where `some_very_fast_sum_on_variadic_packs` would put the `xs` in an array and then return a `int_`. However, in `fold_mcd`, `unpack` is implemented inefficiently, and in `unpack_mcd`, `fold` is decent but it is still likely not as efficient as a user-provided one. Which implementation for `sum` do I choose? If I pick the first one, it's going to be suboptimal with objects that used `unpack_mcd`. If I pick the second one, it's going to be suboptimal with objects that used `fold_mcd`.

But as user if I was defining my own `sum` function, how would I do it? I can't change the typeclass, since it is in another library. Is there a way for me as an user to optimize my sum function based on which MCD was implemented? And if so, couldn't the library do the same?

If you go look at the Foldable type class in Haskell, you'll see that there are a bunch of related functions provided with the type class, yet they are not included in it. My opinion is that they might just as well be included in the type class, as you could then redefine them for improved performance. I just searched online for a rationale or at least some insight about this decision, but I did not find anything.

I think the rational is similar to the rational for using non-member functions. One reason is consistency. People are going to add new algorithms, but they won't be added to the typeclass. Futhermore, if they want to allow overloading the algorithm for optimization, they will create new typeclasses. So now you have two different ways to accomplish the same thing. Another reason, is it will make the typeclass simpler and improve encapsulation. A typeclass is defined by the minimum necessary and not by another 50 algorithms.

That being said, Monads are a common hurdle for people learning FP (I myself am super new to this stuff, BTW) and I'm not sure changing the name would do any good. To grok Monads, you have to bang your head a bit, not think of them as one particular metaphor[1]. Also, FWIW, I think that defining Monads with `join` (as in Hana) instead of `bind` (as in Haskell) makes them easier to understand, but that's just me.

I do agree that `join` is easier than `bind`.

Yup, you're missing `cons` and `nil`. But you're right that `List` can be refactored, and I plan to do it. For example, `filter` can be implemented if you give me `nil` and a `Monad`, which makes a `MonadZero` (a Monad with a neutral element):

// pseudo code auto filter = [](auto pred, auto xs) { auto go = [=](auto x) { return pred(x) ? lift(x) : nil; }; return join(fmap(go, xs)); };

You get `fmap` from Functor, `lift` from Applicative and `nil` from MonadZero. Then you can filter Maybes, with `nil` being `nothing`!

Awesome.

...

- It's important to note that the `decltype_` function will only work for constexpr-friendly types.

I don't get it? Can you please expand?

I should clarify that I'm referring to the use of `decltype_` within the context of constexpr. It will work outside of that. So, for example, if I were to static_assert that two types were the same, as a simple example: template<class T> void foo(T x) { auto y = bar(); static_assert(decltype_(x) == decltype_(y), "Not matching types"); } This won't work for if types are not a literal type nor have a constexpr constructed. This will fail even if `decltype_` was to take the expression by reference. Ultimately, I believe the language should be changed to allow for this. -- 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.

Well, if you define the `sum` function, that's because you are defining an instance of the corresponding type class (Foldable). Hence, you are already choosing the MCD:

namespace boost { namespace hana { template <> struct Foldable::instance<YourDatatype> : Foldable::the_mcd_you_want { // minimal complete definition here

template <typename Xs> static constexpr auto sum_impl(Xs xs) { // your custom sum implementation } }; }} // end namespace boost::hana

Am I missing your point?

Yes, I shouldn't have used `sum` as an example. So say a another library wants to implement `xor` or `bitand`, can they use different MCDs to optimize it like what `sum` does? And if they can, then `sum` could do the same thing as well. If they cannot, then this should be fixed. Its not possible to think of every single fold algorithms and put it into a typeclass beforehand.

The truth is that I think users should not feel the need to add methods to existing type classes. If a method can be implemented in a type class _and_ has a general utility, then it should be added to the type class for everyone to benefit. If, however, you need more "structure" than provided by existing type classes to do something, then you create a new type class which carries that additional "structure" and in which you can implement more operations. That's how I see it.

It should be possible to build on top of your library to create general utilities without requiring the user to patch your library.

It should work; Hana was designed exactly to deal with that. Here's what happens (that's going to be in the tutorial also):

1. decltype_(x) == decltype_(y) returns a bool_<true or false> 2. bool_* has a constexpr conversion to bool defined as:

template <bool b> struct bool_type { constexpr operator bool() const { return b; } };

Since the conversion is always constexpr, it's used in the `static_assert` and it works. Now, it does not __actually__ works because of what I think is a bug in Clang. For it to work, you have to define a dummy object like that:

template void foo(X x, Y y) { auto dummy_result = decltype_(x) == decltype_(y); static_assert(dummy_result, ""); }

And that will compile. Am I exploiting some hole in Clang or is this correct w.r.t. C++14? I'm unfortunately not really a standards guy, so if someone can help here that'd be helpful.

According to my understanding of the language, if you try to call `foo` with `std::vector` it will fail, since `std::vector` is not a literal type nor is it constexpr-constructible. If it does work on clang using the dummy variable trick then it looks like you are exposing a hole in Clang. Of course, I coulde be wrong. -- 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.

On 7/29/2014 2:17 PM, pfultz2 wrote:

Here's a few list of names off the top of my head that could use more C++-like names:

foldl = fold foldr = reverse_fold fmap = transform cons = push_front scons = push_back datatype = tag,tag_of head = front last = back typeclass = concept

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. \e

pfultz2 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

Bjorn Reese writes:

On 07/30/2014 11:53 PM, Louis Dionne wrote:

...

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.

I do not associate 'apply' with computation. The documentation of hana::bind states that it "Appl[ies] a function returning a monad to the value(s) inside a monad", so 'apply' does not seem like such a bad name.

`apply` is already used for the same purpose as in the MPL: apply(f, args...) == f(args...) Furthermore, `bind` is used as follows: bind(bind(bind(monad, monadic_f), monadic_g), monadic_h) For it to be named `apply`, I'd at least have to reverse the order of the arguments so we can say "apply a monadic function to a monad". I'll think about another name for `bind` but I'm really not sure `apply` is better suited. ------------------- Oh and I just thought about that, but `ap` is also used to apply a function inside an applicative to arguments inside applicatives. So I'm even less sure about `apply` for Monads, since Monads are Applicatives. So you'd have ap(function_inside_monad, argument_inside_monad) apply(function_returning_a_monad, argument_inside_monad) and I think we're in for some confusion if we go with that. Louis

Agustín K-ballo Bergé writes:

[...]

`apply` is also the name chosen by the Library Fundamentals TS for calling a function with a tuple of arguments:

https://rawgit.com/cplusplus/fundamentals-ts/n4023/fundamentals-ts.html#tupl...

I use `unpack` for this, and I think it is more consistent both with the previous use of `apply` in the MPL, and with the expected meaning of `apply`. That's somewhat subjective though. Is there any chance the Fundamentals TS can be influenced? Louis -- 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.

Nathan Crookston writes:

Hi Louis,

[...]

Regarding performance, I note that you have several graphs in the reference section showing (generally) good performance scaling. I think it would be useful to add a section to the manual speaking generally about performance. One common criticism of metaprogramming is the time it takes to compile and link. Addressing it would certainly help someone understand more benefits of the library without having to follow the boost list.

I agree that a section on performance could be useful. At least explaining roughly how performance is measured at compile-time would be a nice to have. At the same time, I'm inclined to think that people who don't know about this stuff are not C++ power users and should not have to worry about it anyway, while those who know don't need it explained to them. Also, one goal of Hana was to make metaprogramming reasonably efficient so you would not actually have to care about this stuff anymore. I'll add a section on performance, or at least how you can maximize performance with Hana, but I don't know in what level of details I'll go, because we could probably write a small book on compile-time performance.

I have a few other suggestions about the documentation that I can send along, if you're looking for that at this point.

Definitely; please shoot anything you've got.

[...]

It sounds like you're already planning to do this, but mentioning type_list<>, even if it's essentially just list(type<>...) would help show that this is a valid replacement for MPL.

I did not mention it anywere because I'd like to see this one go. It's there for performance reasons only, but it's possible to implement those optimizations in `list` without introducing a new container. I've started writing a cheat sheet to translate between MPL and Hana; this should pretty much give you a mechanical transformation for all algorithms written with the MPL.

Do you plan to implement things like MPL's vector_c? I ask because a C++14 units library could be much nicer than the (already nice) boost units library. Using Hana could be nice for compile times.

See integer_list. However, like type_list, I'd like to see this one go. Note that optimizations for homogeneous sequences are not implemented yet (so integer_list is not implemented with an internal always-constexpr array).

[...]

My only concern would be the performance on other compilers once they implement the necessary features. Is there some assurance that the lambda trick would work (i.e. be fast) on g++?

For this, we'll have to run the benchmarks on GCC. The benchmark suite is hooked up in the CMake-generated build system and the benchmarks will run on GCC with 2-3 modifications to a Ruby gem I use internally.

I look forward to playing with this in about a month. I'll definitely post a review if and when a review occurs.

Thanks! Louis

Larry Evans writes:

[...]

I looked at:

http://ldionne.github.io/hana/index.html

but saw no mention of the `let-expressions` that was mentioned here:

http://article.gmane.org/gmane.comp.lib.boost.devel/245231

Did I miss where they are documented or was there some problem in implementing them and, consequently, they were left out?

That was for the MPL11. With Hana, we use generic C++14 lambdas instead, so we don't need that emulation anymore. Regards, Louis

Larry Evans writes:

[...]

The correspondence between the two, IIUC, is the let-expresion:

( let ( [id1 val-expr1] [id2 val-expr2] [id3 val-expr3] ... ) body-expr )

would be, using generic-lambdas:

[] ( auto id1 , auto id2 , auto id3 ) { return body-expr } ( val-expr1 , val-expr2 , val-expr3 ... )

Is that about right?

That would be it, but you could also use the lambda capture. If I remember, my motivation for let expressions was to define branches inline when I had conditionals. Here's what I do in Hana when I want to branch on a (possibly compile-time) condition: auto result = eval_if(condition, [](auto _) { return then_branch; }, [](auto _) { return else_branch; } ); Now, I can use the lambda capture if there's something I need to capture in either branches. I'll explain the dummy argument now. Since we use lambdas, we achieve one level of laziness; we achieve runtime laziness. Only the branch which is chosen by the condition will be executed inside eval_if, so all is good. However, since we also want to support heterogeneous branches, and so branches whose well-formedness might depend on the value of the condition, we use a dummy argument to delay the template instantiation inside the branches. Let's pretend our branches are functions of some arbitrary x: auto result = eval_if(condition, [](auto _) { return then_branch(_(x)); }, [](auto _) { return else_branch(_(x)); } ); Now, because the compiler does not know what is _ until either branch is called, it can't instantiate a (possibly invalid) branch. Then, the trick we play to the compiler is that eval_if always calls us with an identity function, so _(x) is actually x, but not knowing it until the last moment bound the compiler to wait before instantiating the whole expression. This is long, but I hope it clarifies why, IMO, we don't need let expressions anymore. Louis

Karen Shaeffer writes:

[...]

Hi Louis,

I believe the clang C++ language support page claims that clang-3.4 fully supports C++14.

http://clang.llvm.org/cxx_status.html

Could you please explain why I will need clang-3.5 to work with your library?

Clang 3.4 has several C++14-related bugs that are fixed in 3.5, so it segfaults almost instantaneously when you feed it Hana. Regards, Louis