[GSoC][MPL11] Post C++Now update
Dear Boost, A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11. The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far. Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress. Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is. Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test. Roadmap ------- Finish exploring the design space. If it turns out that we can merge the MPL and Fusion, then I'll be working on that for a while. If I find that this is not possible or not a good idea, I'll go back to my initial GSoC planning. In both cases, I hope to have a library in the incubator by the end of the summer. Also, this new roadmap is approved by my mentor. Feel free to reply with questions and/or comments. Regards, Louis [1]: http://ldionne.com/mpl11-cppnow-2014 [2]: http://github.com/ldionne/hana
On 5/19/14, 4:41 AM, Louis Dionne wrote:
After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Been there tried that... This has been proposed several times in the past. I reiterate my position: MPL and Fusion are different beasts and it is not good for both to be merged (if it is at all possible). MPL does not have the runtime components that Fusion needs and Fusion has runtime components that MPL *does not* need. Also, because of the runtime aspects of Fusion, the semantics of algorithms do not make sense in MPL. Take the any algo for example: http://tinyurl.com/mk2whdo Note that odd in that example is a runtime operation. How do you unite that? It works only with fusion sequences (with values) and not with MPL sequences (with types). In MPL, that would be a type-only predicate. If you add values to MPL, it would be 1) unnecessarily more complex than it needs to be and 2) the feature set would be comprised of very ugly mongrels. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
On 5/19/14, 4:41 AM, Louis Dionne wrote:
After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Been there tried that...
This has been proposed several times in the past. I reiterate my position: MPL and Fusion are different beasts and it is not good for both to be merged (if it is at all possible). MPL does not have the runtime components that Fusion needs and Fusion has runtime components that MPL *does not* need.
Also, because of the runtime aspects of Fusion, the semantics of algorithms do not make sense in MPL. Take the any algo for example:
Note that odd in that example is a runtime operation. How do you unite that? It works only with fusion sequences (with values) and not with MPL sequences (with types). In MPL, that would be a type-only predicate.
If you add values to MPL, it would be 1) unnecessarily more complex than it needs to be and 2) the feature set would be comprised of very ugly mongrels.
FWIW, I 100% agree with Joel. Having MPL and Fusion separate is definitely the way to go. Fusion is named the way it is for a reason! If you wanted to combine MPL and Fusion you would have to combine it with the STL by simple extension as well. Moreover, Christopher Schmidt finished a full C++11 rewrite of Fusion during GSoC 2009. It might be a good idea to go back and look what he came up with. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On 5/19/14, 8:47 AM, Hartmut Kaiser wrote:
On 5/19/14, 4:41 AM, Louis Dionne wrote:
After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Been there tried that...
This has been proposed several times in the past. I reiterate my position: MPL and Fusion are different beasts and it is not good for both to be merged (if it is at all possible). MPL does not have the runtime components that Fusion needs and Fusion has runtime components that MPL *does not* need.
Also, because of the runtime aspects of Fusion, the semantics of algorithms do not make sense in MPL. Take the any algo for example:
Note that odd in that example is a runtime operation. How do you unite that? It works only with fusion sequences (with values) and not with MPL sequences (with types). In MPL, that would be a type-only predicate.
If you add values to MPL, it would be 1) unnecessarily more complex than it needs to be and 2) the feature set would be comprised of very ugly mongrels.
FWIW, I 100% agree with Joel. Having MPL and Fusion separate is definitely the way to go. Fusion is named the way it is for a reason! If you wanted to combine MPL and Fusion you would have to combine it with the STL by simple extension as well.
Moreover, Christopher Schmidt finished a full C++11 rewrite of Fusion during GSoC 2009. It might be a good idea to go back and look what he came up with.
The C++11 port is probably not good enough in a C++14 world and now that we know a lot more how to use C++14 properly. Also, my biggest gripe about that port was that it required one big gulp. I insist on incremental updates instead of one big switch. One final point is that the current fusion lib is in active development and incrementally adds more C++11/14 code. I'd welcome co-maintainer(s) to do more work on modernization. Send me an email if interested. That said, I'd also welcome a totally modern C++14 Fusion version, without any C++03-isms and taking advantage of all the cool features of C++14, without any backward compatibility requirements. I'm willing to mentor and direct such an effort. Let's call it Fusion14. I welcome proposals and POCs. (BTW, MPL11 should be MPL14 instead, using all the features of C++14) Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
On Mon, May 19, 2014 at 2:47 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com>wrote:
Moreover, Christopher Schmidt finished a full C++11 rewrite of Fusion during GSoC 2009. It might be a good idea to go back and look what he came up with.
What happened with that rewrite? Are there any plans to review it/merge it with master?
On 5/19/14, 3:49 PM, Gonzalo BG wrote:
On Mon, May 19, 2014 at 2:47 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com>wrote:
Moreover, Christopher Schmidt finished a full C++11 rewrite of Fusion during GSoC 2009. It might be a good idea to go back and look what he came up with.
What happened with that rewrite?
Are there any plans to review it/merge it with master?
See my other post. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
I was one of the people at the conference that tried to convince Louis to approach things this way. I wasn't the only one, and I can only speak for myself. The advantage to me is that I might have a library that I can use to do *both* compile-time only, and runtime+compiletime operations. Now that I have constexpr function and decltype(), I find the lines between compiletime and runtime operations to be sufficiently blurred that I don't draw the clear distinction I once did. For instance, in C++14, I can simply elide certain metafunctions I used to require to compute the return values of certain functions -- anything that can be done with a fold can be written in the form "auto foo (args) { return fold(some_fn, args); }". This makes me gravitate towards a solution that marries runtime and compile time as much as possible. That being said, it doesn't look like Louis is committed to one approach or another yet; he is still investigating. Also, he is not committed to making a drop-in Fusion replacement, just an updated MPL for C++11/14. He is simply trying to incorporate Fusion-like elements in that where they are appropriate. Louis, please correct me if I'm mistaken. Zach On Mon, May 19, 2014 at 5:21 AM, Joel de Guzman <djowel@gmail.com> wrote:
On 5/19/14, 3:49 PM, Gonzalo BG wrote:
On Mon, May 19, 2014 at 2:47 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com
wrote:
Moreover, Christopher Schmidt finished a full C++11 rewrite of Fusion
during GSoC 2009. It might be a good idea to go back and look what he came up with.
What happened with that rewrite?
Are there any plans to review it/merge it with master?
See my other post.
Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On 5/19/14, 9:11 PM, Zach Laine wrote:
I was one of the people at the conference that tried to convince Louis to approach things this way. I wasn't the only one, and I can only speak for myself. The advantage to me is that I might have a library that I can use to do *both* compile-time only, and runtime+compiletime operations. Now that I have constexpr function and decltype(), I find the lines between compiletime and runtime operations to be sufficiently blurred that I don't draw the clear distinction I once did. For instance, in C++14, I can simply elide certain metafunctions I used to require to compute the return values of certain functions -- anything that can be done with a fold can be written in the form "auto foo (args) { return fold(some_fn, args); }". This makes me gravitate towards a solution that marries runtime and compile time as much as possible.
That being said, it doesn't look like Louis is committed to one approach or another yet; he is still investigating. Also, he is not committed to making a drop-in Fusion replacement, just an updated MPL for C++11/14. He is simply trying to incorporate Fusion-like elements in that where they are appropriate. Louis, please correct me if I'm mistaken.
Sounds very cool. I'd love to see a proof of concept toy example. Anyone? My concern here is that constexpr has severe limitations. I wonder how useful a fusion library based on constexpr will be. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
Joel de Guzman <djowel <at> gmail.com> writes:
On 5/19/14, 9:11 PM, Zach Laine wrote:
[...]
That being said, it doesn't look like Louis is committed to one approach or another yet; he is still investigating. Also, he is not committed to making a drop-in Fusion replacement, just an updated MPL for C++11/14. He is simply trying to incorporate Fusion-like elements in that where they are appropriate. Louis, please correct me if I'm mistaken.
That's correct. I'm just trying to figure whether it is possible/desirable to have a universal metaprogramming library for C++. Also, there are no plans to build a drop-in replacement for Fusion. Whatever I come up with won't be backward compatible with Fusion because it won't use iterators, which I consider as a design flaw. It won't be backward compatible with the MPL for the same reason.
Sounds very cool. I'd love to see a proof of concept toy example. Anyone? My concern here is that constexpr has severe limitations. I wonder how useful a fusion library based on constexpr will be.
http://github.com/ldionne/hana Regards, Louis Dionne
On Mon, May 19, 2014 at 1:59 PM, Louis Dionne <ldionne.2@gmail.com> wrote:
Joel de Guzman <djowel <at> gmail.com> writes:
On 5/19/14, 9:11 PM, Zach Laine wrote:
[...]
That being said, it doesn't look like Louis is committed to one
another yet; he is still investigating. Also, he is not committed to making a drop-in Fusion replacement, just an updated MPL for C++11/14. He is simply trying to incorporate Fusion-like elements in that where
approach or they are
appropriate. Louis, please correct me if I'm mistaken.
That's correct. I'm just trying to figure whether it is possible/desirable to have a universal metaprogramming library for C++.
Also, there are no plans to build a drop-in replacement for Fusion. Whatever I come up with won't be backward compatible with Fusion because it won't use iterators, which I consider as a design flaw. It won't be backward compatible with the MPL for the same reason.
Sounds very cool. I'd love to see a proof of concept toy example. Anyone? My concern here is that constexpr has severe limitations. I wonder how useful a fusion library based on constexpr will be.
http://github.com/ldionne/hana
Regards, Louis Dionne
Is the issue the name, MPL11? These proposals seem to be more Fusion11. The current MPL has type-computation and compile-time value computation. It supports sequences of types and sequences of homogeneous values. It seems that people want the compile-time value computation written in the runtime language, as opposed to the compile time language. I like this idea too. But I'm not seeing a reason to do type-computation in the runtime-language. For example, take this in the current current MPL: template<bool IsOrdered> struct Values { boost::mpl::if_c<IsOrdered, std::set<int>, std::unordered_set<int>>::type values; }; And then in the runtime MPL that Louis posted earlier: template<bool IsOrdered> struct Values { decltype(boost::mpl::if_c(declval(mpl::bool_<IsOrdered>), declval(std::set<int>), declval(std::unordered_set<int>))) values; }; That seems like a step backward to me. It is possible to "stitch" together the runtime and compile languages with the expanded "using" keyword, but is that the right approach? What would be the benefit of the current MPL for these sorts of type computations? Maybe the goal is to have the compile-time value computation merged into a new iteration of a fusion-like library. All of the Fusion functions could work with std::tuple or std::integer_sequence, which is equivalent to fusion::vector and mpl::vector_c<int, ...> respectively. Lee
Lee Clagett <forum <at> leeclagett.com> writes: [...]
Is the issue the name, MPL11? These proposals seem to be more Fusion11. The
The name's not the issue. The new library is called Boost.Hana and as long as it does not conflict with anything, I'm unwilling to discuss it; that would be bikeshedding. It's just a name after all.
current MPL has type-computation and compile-time value computation. It supports sequences of types and sequences of homogeneous values. It seems that people want the compile-time value computation written in the runtime language, as opposed to the compile time language. I like this idea too. But I'm not seeing a reason to do type-computation in the runtime-language.
If doing so allows us to have a single library instead of two libraries with different interfaces, that's a reason. It would also mean that some functions written for runtime arguments could work as-is on types, which is an advantage. Finally, Matt Calabrese already pointed out the ease of debugging metaprograms. There might be other less obvious advantages too.
For example, take this in the current current MPL:
template<bool IsOrdered> struct Values { boost::mpl::if_c<IsOrdered, std::set<int>, std::unordered_set<int>>::type values; };
And then in the runtime MPL that Louis posted earlier:
template<bool IsOrdered> struct Values { decltype(boost::mpl::if_c(declval(mpl::bool_<IsOrdered>), declval(std::set<int>), declval(std::unordered_set<int>))) values; };
With Boost.Hana, that would actually be template <bool IsOrdered> struct Values { static constexpr auto values_t = if_(bool_<IsOrdered>, type<std::set<int>>, type<std::unordered_set<int>> ); typename decltype(values_t)::type values; }; which is worse than the current MPL. However, perhaps sticking to simple tools is better for simple problems: template <bool IsOrdered> struct Values { using values_t = std::conditional_t<IsOrdered, std::set<int>, std::unordered_set<int> >; values_t values; }; I'll admit that I would like these simple problems to have a simple solution in Boost.Hana. It might be possible by providing thin wrappers for type-only computations; I'll evaluate that and provide feedback.
That seems like a step backward to me. It is possible to "stitch" together the runtime and compile languages with the expanded "using" keyword, but is
I'm sorry, but I don't see how the "using" keyword helps at all here. Could you please expand? [...] Regards, Louis Dionne
On Tue, May 20, 2014 at 3:53 PM, Louis Dionne <ldionne.2@gmail.com> wrote:
Lee Clagett <forum <at> leeclagett.com> writes:
With Boost.Hana, that would actually be
template <bool IsOrdered> struct Values { static constexpr auto values_t = if_(bool_<IsOrdered>, type<std::set<int>>, type<std::unordered_set<int>> ); typename decltype(values_t)::type values; };
which is worse than the current MPL. However, perhaps sticking to simple tools is better for simple problems:
template <bool IsOrdered> struct Values { using values_t = std::conditional_t<IsOrdered, std::set<int>, std::unordered_set<int> >; values_t values; };
I'll admit that I would like these simple problems to have a simple solution in Boost.Hana. It might be possible by providing thin wrappers for type-only computations; I'll evaluate that and provide feedback.
That syntax isn't so bad, maybe its just a matter of getting used to a different style. The unfortunate part are the type<> wrappers. Larger expressions could look unsightly.
That seems like a step backward to me. It is possible to "stitch" together the runtime and compile languages with the expanded "using" keyword, but is
I'm sorry, but I don't see how the "using" keyword helps at all here. Could you please expand?
Type aliasing can be combined with type introspection (decltype) to get an existing MPL style: template<bool Conditional, typename Then, typename Else> using if_d = typename std::result_of< boost::hana::_if( boost::hana::Bool<Conditional>, boost::hana::Type<Then>, boost::hana::Type<Else>)>::type; template<bool Ordered> using map_type_t = typename if_d<Ordered, std::set<int>, std::unordered_set<int>>::type; static_assert( std::is_same<map_type_t<true>, std::set<int>>::value, "expected ordered"); static_assert( std::is_same<map_type_t<false>, std::unordered_set<int>>::value, "expected unordered"); I used result_of instead of decltype directly, it looks a little nicer I think. The syntax would even work with MPL value computations like count_if, assuming a Integral<0> could be used as the initial value (I think it can in the hana design). The trick is returning an integral<> in that situation, otherwise decltype isn't computing a useful value. The only place I know this gets complicated is with lambda expressions, not sure how that would be merged. Lee
On Mon, May 19, 2014 at 6:11 AM, Zach Laine <whatwasthataddress@gmail.com>wrote:
I was one of the people at the conference that tried to convince Louis to approach things this way. I wasn't the only one, and I can only speak for myself. The advantage to me is that I might have a library that I can use to do *both* compile-time only, and runtime+compiletime operations. Now that I have constexpr function and decltype(), I find the lines between compiletime and runtime operations to be sufficiently blurred that I don't draw the clear distinction I once did. For instance, in C++14, I can simply elide certain metafunctions I used to require to compute the return values of certain functions -- anything that can be done with a fold can be written in the form "auto foo (args) { return fold(some_fn, args); }". This makes me gravitate towards a solution that marries runtime and compile time as much as possible.
I, too, am in support of this and stand by it being an ideal, unless that ideal proves unfeasible to implement or use. Louis also noticed one huge advantage of this that cannot be understated -- if a new mpl is implemented using the automatic return type deduction approach, regardless of whether or not it is actually merged with fusion, it provides a very powerful way to debug metaprograms -- simply call the function without decltype but with the same parameters and you can then step through the code in your favorite debugger at runtime, including the ability to set breakpoints and step through line by line. Just make sure that you force your arguments to not be constexpr so that the evaluation happens at runtime for the sake of debugging. -- -Matt Calabrese
On 5/20/14, 1:34 AM, Matt Calabrese wrote:
On Mon, May 19, 2014 at 6:11 AM, Zach Laine <whatwasthataddress@gmail.com>wrote:
I was one of the people at the conference that tried to convince Louis to approach things this way. I wasn't the only one, and I can only speak for myself. The advantage to me is that I might have a library that I can use to do *both* compile-time only, and runtime+compiletime operations. Now that I have constexpr function and decltype(), I find the lines between compiletime and runtime operations to be sufficiently blurred that I don't draw the clear distinction I once did. For instance, in C++14, I can simply elide certain metafunctions I used to require to compute the return values of certain functions -- anything that can be done with a fold can be written in the form "auto foo (args) { return fold(some_fn, args); }". This makes me gravitate towards a solution that marries runtime and compile time as much as possible.
I, too, am in support of this and stand by it being an ideal, unless that ideal proves unfeasible to implement or use. Louis also noticed one huge advantage of this that cannot be understated -- if a new mpl is implemented using the automatic return type deduction approach, regardless of whether or not it is actually merged with fusion, it provides a very powerful way to debug metaprograms -- simply call the function without decltype but with the same parameters and you can then step through the code in your favorite debugger at runtime, including the ability to set breakpoints and step through line by line. Just make sure that you force your arguments to not be constexpr so that the evaluation happens at runtime for the sake of debugging.
Wow, that is awesome! I wanted to be able to do that for a long time! Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
Hartmut Kaiser <hartmut.kaiser <at> gmail.com> writes: [...]
FWIW, I 100% agree with Joel. Having MPL and Fusion separate is definitely the way to go. Fusion is named the way it is for a reason! If you wanted to combine MPL and Fusion you would have to combine it with the STL by simple extension as well.
I think it totally makes sense to adapt some components of the STL. Constexpr containers like `std::array`, `std::tuple` and `std::integer_sequence` are straightforward, but runtime-only containers like `std::vector` are giving me problems right now. I'm searching for a solution. See [1] for an example of using `std::array`.
Moreover, Christopher Schmidt finished a full C++11 rewrite of Fusion during GSoC 2009. It might be a good idea to go back and look what he came up with.
Thanks for the heads up. Is there a link to that code, or is it already in the Boost distribution? I did find a C++11 implementation of fusion::map in fusion/container/map/detail/map_impl.hpp, but is that all? Regards, Louis Dionne [1]: https://github.com/ldionne/hana/blob/master/test/std_array.cpp
On 05/19/14 12:42, Louis Dionne wrote:
Hartmut Kaiser <hartmut.kaiser <at> gmail.com> writes: [snip]
Moreover, Christopher Schmidt finished a full C++11 rewrite of Fusion during GSoC 2009. It might be a good idea to go back and look what he came up with.
Thanks for the heads up. Is there a link to that code, or is it already in the Boost distribution? [snip] Unfortunately not. There is this:
http://svn.boost.org/svn/boost/sandbox/SOC/2009/fusion/README however, the link mentioned there no longer works. I did work some with Christopher in comparing implementations of tuple. The mailing list thread starts here: http://article.gmane.org/gmane.comp.lib.boost.devel/194327 I do have some downloads of the slim code he mentioned in the README link; however, IIRC the code here: https://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/slim/test... contains a simplified version of the slim code which may give you some idea of how it was implemented. IIRC, the boost pp was used somewhat like the current fusion uses it; however, Christopher used inheritance to provide the tail of the tuple. Also, just like fusion, Christopher divided the tuple into "chunks" of a given size, which, IIRC, was 10. Each chunk, like fusion, had variables m1...m10 declared with T1...T10 which were the head template arguments. Have a look at: https://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/slim/test... for a more concrete idea (I'd suggest running through the preprocessor then indent, to make things clearer). I think the chunk size is given by the UNROLL_MAX macro in that file. However, I've just briefly glanced over the code again; so, this explanation may be a bit flawed. HTH. -regards, Larry
Joel de Guzman <djowel <at> gmail.com> writes:
On 5/19/14, 4:41 AM, Louis Dionne wrote:
After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Been there tried that...
This has been proposed several times in the past. I reiterate my position: MPL and Fusion are different beasts and it is not good for both to be merged (if it is at all possible). MPL does not have the runtime components that Fusion needs and Fusion has runtime components that MPL *does not* need.
This is true, the MPL does not _need_ a runtime component. Adding one should be harmless if done correctly. There might be a performance penalty though, but I'll benchmark that eventually.
Also, because of the runtime aspects of Fusion, the semantics of algorithms do not make sense in MPL. Take the any algo for example:
Note that odd in that example is a runtime operation. How do you unite that? It works only with fusion sequences (with values) and not with MPL sequences (with types). In MPL, that would be a type-only predicate.
As of writing this, here is what I am able to do [1]: Purely runtime predicate ------------------------ struct odd { template <typename T> bool operator()(T t) const { return t % 2; } }; assert(any(odd{}, list(1, 2))); assert(!any(odd{}, list(2, 4))); Constexpr predicate ------------------- struct odd { template <typename T> constexpr bool operator()(T t) const { return t % 2; } }; static_assert(any(odd{}, list(1, 2)), ""); static_assert(!any(odd{}, list(2, 4)), ""); Type-only predicate ------------------- struct odd { template <typename T> constexpr auto operator()(T t) const { return t % int_<2>; } }; static_assert(std::is_same< decltype(any(odd{}, list(int_<1>, int_<2>))), Bool<true> >::value, ""); static_assert(std::is_same< decltype(any(odd{}, list(int_<2>, int_<4>))), Bool<false> >::value, ""); The trick for the type-only predicate is that there exists an overload template <int i, int j> constexpr Int<i % j> operator%(Int<i>, Int<j>) { return {}; } where Int<...> is the type of int_<...>. Since int_<...> is implicitly constexpr convertible to int, one can just write the predicate as struct odd { template <typename T> constexpr auto operator()(T t) const { return t % int_<2>; } }; and use it in the three examples. So there is no code duplication and purely compile-time functions can now also be used as runtime or constexpr functions for free. This is a large gain IMO. As far as I can see, everything that can be done with the MPL may also be done with a variation of this technique. For an example, see [2].
If you add values to MPL, it would be 1) unnecessarily more complex than it needs to be
I don't see why that should be, and my experience suggests something different. Could you please expand on this point and/or provide evidence backing this claim?
and 2) the feature set would be comprised of very ugly mongrels.
Again, I don't see why that should be and my experience suggests that this is not the case. Regards, Louis Dionne [1]: https://github.com/ldionne/hana/blob/master/test/misc/fusion_any.cpp [2]: https://github.com/ldionne/hana/blob/master/test/type/mpl_equivalent.cpp
On 19/05/2014 02:28 p.m., Louis Dionne wrote:
Joel de Guzman <djowel <at> gmail.com> writes:
On 5/19/14, 4:41 AM, Louis Dionne wrote:
After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Been there tried that...
This has been proposed several times in the past. I reiterate my position: MPL and Fusion are different beasts and it is not good for both to be merged (if it is at all possible). MPL does not have the runtime components that Fusion needs and Fusion has runtime components that MPL *does not* need.
This is true, the MPL does not _need_ a runtime component. Adding one should be harmless if done correctly. There might be a performance penalty though, but I'll benchmark that eventually.
Having done my own research on what a C++11/14 aware Fusion library would be, I concur with Louis. The optimal implementation for sequences and (most) algorithms look the same for MPL and Fusion, where the MPL implementation is built by wrapping and unwrapping arguments around Fusion calls. Additionally, while I wouldn't go as far as to say that iterators are a design flaw, they do get in the way of reducing compilation time while offering no real advantage (iterators are a compile-time thing in both libraries after all). I would like to encourage Louis to experiment with this approach, as long as it doesn't compromise the goal of optimal compilation times for MPL. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On 05/19/2014 10:28 AM, Louis Dionne wrote:
Type-only predicate ------------------- struct odd { template <typename T> constexpr auto operator()(T t) const { return t % int_<2>; } };
static_assert(std::is_same< decltype(any(odd{}, list(int_<1>, int_<2>))), Bool<true> >::value, "");
What does it look like to have a compile-time list containing void? Or an array type? Or a function type (i.e., not a pointer to function)? Or an abstract type? Eric
What does it look like to have a compile-time list containing void? Or an array type? Or a function type (i.e., not a pointer to function)? Or an abstract type?
Plus, constexpr's parameters must all be literal types. Paul On Monday, May 19, 2014 7:05 PM, Eric Niebler <eniebler@boost.org> wrote:
On 05/19/2014 10:28 AM, Louis Dionne wrote:
Type-only predicate ------------------- struct odd { template <typename T> constexpr auto operator()(T t) const { return t % int_<2>; } };
static_assert(std::is_same< decltype(any(odd{}, list(int_<1>, int_<2>))), Bool<true> >::value, "");
What does it look like to have a compile-time list containing void? Or an array type? Or a function type (i.e., not a pointer to function)? Or an abstract type?
Eric
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think the emphasis is a little too focused on compilation times and not enough on the interface. That being said, a comment about the type-only predicate: Thanks to constexpr, function overloading, user-defined literals, explicit operator bool, and variable templates, that example could actually look like this: static_assert(any(odd{}, list(1_udl, 2_udl)), "1 or 2 should be odd."); And also allow the following natural looking expressions: static_assert(count(odd{}, list(1_udl, 2_udl, 3_udl)) == 2_udl, "Incorrect count of odd numbers."); static_assert(type<int> == type<decltype(0)>, "Integer literal not an int."); static_assert(common_type(type<int>, type<unsigned>, type<char>, type<signed char>) == type<unsigned>, "Incorrect common_type."); User-defined literal name of udl (user defined literal) chosen as a placeholder to avoid that being the focus. It could be anything from _mpl to _type to _t. Long compile times in a C++11 metaprogramming world are primarily defined by the number of arguments passed to constexpr functions (calling two constexpr functions with 3000 arguments instead of one constexpr function with 3000 arguments is a huge time and memory sink) and template instantiation / constexpr recursion depth. Neither of those are especially dictated by choice in interface, and I would hate to see a better interface abandoned due to premature optimization.
Minor addition to my previous post: By converting a type to a value by way of the type<> variable template, you can mix types and values interchangeably. That second example I gave could also be written as static_assert(count(odd{}, list(1_udl, 2_udl, 3_udl)) == 2, "Incorrect count of odd numbers."); and everything would work as expected. It is these types of interfaces that allow seamless transitions between compile-time and run-time computations.
Eric Niebler <eniebler <at> boost.org> writes:
On 05/19/2014 10:28 AM, Louis Dionne wrote:
Type-only predicate ------------------- struct odd { template <typename T> constexpr auto operator()(T t) const { return t % int_<2>; } };
static_assert(std::is_same< decltype(any(odd{}, list(int_<1>, int_<2>))), Bool<true> >::value, "");
What does it look like to have a compile-time list containing void? Or an array type? Or a function type (i.e., not a pointer to function)? Or an abstract type?
static_assert( fmap(trait::add_pointer, list_t<void, int(), char[10]>) == list_t<void*, int(*)(), char(*)[10]> , ""); static_assert( head(fmap(trait::add_pointer, list_t<void, int, char>)) == type<void*> , ""); static_assert(std::is_same< decltype( head(fmap(trait::add_pointer, list_t<void, int, char>)) )::type, void* >::value, ""); Here's how it works. We provide the following helper for convenience: template <typename ...Xs> constexpr auto list_t = list(type<Xs>...); where type<T> is a constexpr variable template of type Type<T>. Type<T> provides a nested ::type alias to T and also provides adapted versions of the type_traits as constexpr functions. For example, it is possible to write static_assert(trait::add_pointer(type<T>) == type<T*>, ""); static_assert(std::is_same<decltype(type<T*>)::type, T*>::value, ""); Note that type<T> == type<U> is (roughly) equivalent to std::is_same<T, U>. The way I see it is that we're trying to represent types as constexpr objects. When trying to do that, a natural question is: what are the "methods" of these objects? What are the operations that we can do on those objects? The answer to that is "whatever operation we can do on a type", which correspond exactly to the type_traits. So type_traits end up being the API of objects of type Type<...>, which are nothing but a special case of compile-time-manipulable objects. When we see things this way, it seems natural to think of the MPL as a special case of heterogeneous constexpr computation. There is still one problem that has to do with ADL (it is not limited to type<>): template <bool b = false> struct invalid { static_assert(b, "can't instantiate invalid<>"); }; static_assert(type<invalid<>> != type<void>, ""); This is going to assert in invalid<> because the ADL required by != will trigger the instantiation of invalid<> . One obvious workaround is to provide named operators like not_equal, but real operators provide a large plus for legibility. If someone has an idea, please let me know. Regards, Louis Dionne
On 5/20/14, 1:28 AM, Louis Dionne wrote:
Joel de Guzman <djowel <at> gmail.com> writes:
On 5/19/14, 4:41 AM, Louis Dionne wrote:
After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Been there tried that...
This has been proposed several times in the past. I reiterate my position: MPL and Fusion are different beasts and it is not good for both to be merged (if it is at all possible). MPL does not have the runtime components that Fusion needs and Fusion has runtime components that MPL *does not* need.
This is true, the MPL does not _need_ a runtime component. Adding one should be harmless if done correctly. There might be a performance penalty though, but I'll benchmark that eventually.
Also, because of the runtime aspects of Fusion, the semantics of algorithms do not make sense in MPL. Take the any algo for example:
Note that odd in that example is a runtime operation. How do you unite that? It works only with fusion sequences (with values) and not with MPL sequences (with types). In MPL, that would be a type-only predicate.
As of writing this, here is what I am able to do [1]:
Purely runtime predicate ------------------------ struct odd { template <typename T> bool operator()(T t) const { return t % 2; } };
assert(any(odd{}, list(1, 2))); assert(!any(odd{}, list(2, 4)));
Constexpr predicate ------------------- struct odd { template <typename T> constexpr bool operator()(T t) const { return t % 2; } };
static_assert(any(odd{}, list(1, 2)), ""); static_assert(!any(odd{}, list(2, 4)), "");
Type-only predicate ------------------- struct odd { template <typename T> constexpr auto operator()(T t) const { return t % int_<2>; } };
static_assert(std::is_same< decltype(any(odd{}, list(int_<1>, int_<2>))), Bool<true> >::value, "");
static_assert(std::is_same< decltype(any(odd{}, list(int_<2>, int_<4>))), Bool<false> >::value, "");
The trick for the type-only predicate is that there exists an overload
template <int i, int j> constexpr Int<i % j> operator%(Int<i>, Int<j>) { return {}; }
where Int<...> is the type of int_<...>. Since int_<...> is implicitly constexpr convertible to int, one can just write the predicate as
struct odd { template <typename T> constexpr auto operator()(T t) const { return t % int_<2>; } };
and use it in the three examples. So there is no code duplication and purely compile-time functions can now also be used as runtime or constexpr functions for free. This is a large gain IMO.
As far as I can see, everything that can be done with the MPL may also be done with a variation of this technique. For an example, see [2].
Amazing! Now that looks like a game changer. I think you are getting me convinced! I like it!
If you add values to MPL, it would be 1) unnecessarily more complex than it needs to be
I don't see why that should be, and my experience suggests something different. Could you please expand on this point and/or provide evidence backing this claim?
No. That was based on past experiences with pre C++11 compilers. If you can do this right with a reasonably small overhead and still support the most important use cases of Fusion, then I'm all for it.
and 2) the feature set would be comprised of very ugly mongrels.
Again, I don't see why that should be and my experience suggests that this is not the case.
Regards, Louis Dionne
[1]: https://github.com/ldionne/hana/blob/master/test/misc/fusion_any.cpp [2]: https://github.com/ldionne/hana/blob/master/test/type/mpl_equivalent.cpp
That is very nice, Louis! Let's see how this goes. Go for it! Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
On 05/18/14 15:41, Louis Dionne wrote:
Dear Boost,
A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11.
The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far.
Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is.
Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test.
As mentioned in this post: https://groups.google.com/forum/?hl=en#!msg/comp.std.c++/_-6X_xZlKlA/-HhvKh5... One use case is:
3) A guaranteed non-recursive way to access elements of parameter packs
and Doug Gregor (quoting from above post) says: This is probably the most-requested feature for variadic templates, and it never it made it because we never found a good, unambiguous syntax. The attached seems to do that. What about adding something like this to the library? -regards, Larry
On 05/20/14 13:59, Larry Evans wrote:
On 05/18/14 15:41, Louis Dionne wrote: [snip]
Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test.
As mentioned in this post:
https://groups.google.com/forum/?hl=en#!msg/comp.std.c++/_-6X_xZlKlA/-HhvKh5...
One use case is:
3) A guaranteed non-recursive way to access elements of parameter packs
and Doug Gregor (quoting from above post) says:
This is probably the most-requested feature for variadic templates, and it never it made it because we never found a good, unambiguous syntax.
The attached seems to do that. What about adding something like this to the library?
-regards, Larry
I should clarify something from my previous post. The at_c.cpp attachment to my previous post *did* use recursion; however, it was template function recursion, not template metafunction recursion. According to: http://cpptruths.blogspot.com/2011/07/want-speed-use-constexpr-meta.html template function recursion *should* compile faster than template metafunction recursion. Although the above web page uses constexpr, there's no need for that in the at_c.cpp attachment because only the types are used, not the values (hence, the functions don't need to be defined). Sorry for being unclear. -regards, Larry
I've seen function template vs. metafunction template instantiations profiled before, and I did it myself a few years ago. Function templates have been slower in every profile I've seen. In my profilings, they were ~20% slower. The linked article appears to get better results not by using constexpr alone, but by using it to do numeric computations that allow it to reduce template instantiations. When the instantiations are close to the same in number, constexpr is slower. In your attachment, it appears that you are iterating over types, and so constexpr and metafunction approaches should involve the same number of template instantiations. Zach On Tue, May 20, 2014 at 3:20 PM, Larry Evans <cppljevans@suddenlink.net>wrote:
On 05/20/14 13:59, Larry Evans wrote:
On 05/18/14 15:41, Louis Dionne wrote:
[snip]
Request for guinea pigs
----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test.
As mentioned in this post:
https://groups.google.com/forum/?hl=en#!msg/comp.std.c++ /_-6X_xZlKlA/-HhvKh5ccEAJ
One use case is:
3) A guaranteed non-recursive way to access elements of parameter packs
and Doug Gregor (quoting from above post) says:
This is probably the most-requested feature for variadic templates, and it never it made it because we never found a good, unambiguous syntax.
The attached seems to do that. What about adding something like this to the library?
-regards, Larry
I should clarify something from my previous post.
The at_c.cpp attachment to my previous post *did* use recursion; however, it was template function recursion, not template metafunction recursion.
According to:
http://cpptruths.blogspot.com/2011/07/want-speed-use-constexpr-meta.html
template function recursion *should* compile faster than template metafunction recursion. Although the above web page uses constexpr, there's no need for that in the at_c.cpp attachment because only the types are used, not the values (hence, the functions don't need to be defined).
Sorry for being unclear.
-regards, Larry
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On 05/20/14 15:48, Zach Laine wrote:
I've seen function template vs. metafunction template instantiations profiled before, and I did it myself a few years ago. Function templates have been slower in every profile I've seen. In my profilings, they were ~20% slower.
The linked article appears to get better results not by using constexpr alone, but by using it to do numeric computations that allow it to reduce template instantiations.
AFAICT, the number of template function instantiations in the linked article are the same as the number of template class instantiations. When I run the attached, 1st with: defined(CONSTEXPR) then with: !defined(COnSTEXPR) the same values appear in the: (yesno,recurs) output, indicating the same number of instantiations. Am I missing something? BTW, I've asked a similar question on the linked page.
When the instantiations are close to the same in number, constexpr is slower. In your attachment, it appears that you are iterating over types, and so constexpr and metafunction approaches should involve the same number of template instantiations.
Zach
On Tue, May 20, 2014 at 3:20 PM, Larry Evans <cppljevans@suddenlink.net>wrote: [snip]
According to:
http://cpptruths.blogspot.com/2011/07/want-speed-use-constexpr-meta.html
template function recursion *should* compile faster than template metafunction recursion. [snip]
On Sat, May 31, 2014 at 4:54 PM, Larry Evans <cppljevans@suddenlink.net> wrote:
On 05/20/14 15:48, Zach Laine wrote:
I've seen function template vs. metafunction template instantiations profiled before, and I did it myself a few years ago. Function templates have been slower in every profile I've seen. In my profilings, they were ~20% slower.
The linked article appears to get better results not by using constexpr alone, but by using it to do numeric computations that allow it to reduce template instantiations.
AFAICT, the number of template function instantiations in the linked article are the same as the number of template class instantiations.
When I run the attached, 1st with:
defined(CONSTEXPR)
then with:
!defined(COnSTEXPR)
the same values appear in the:
(yesno,recurs)
output, indicating the same number of instantiations.
Am I missing something?
Yes. The two approaches are performing the same number of steps, but one is using template instantiations to do so and the other is not. Note the lack of the "template" keyword anywhere in your constexpr version. The compiler must do the same number of steps in both cases, but evaluating a constexpr function at compile time N times and instantiating N templates is not the same thing, and does not compile at the same speed; the template instantiations take longer. If you had instead implemented the constexpr version using size_t template parameters instead of function parameters, I'm pretty confident the constexpr version would compile more slowly. Zach
On 2014-05-20 20:59, Larry Evans wrote:
On 05/18/14 15:41, Louis Dionne wrote:
Dear Boost,
A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11.
The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far.
Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is.
Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test.
As mentioned in this post:
https://groups.google.com/forum/?hl=en#!msg/comp.std.c++/_-6X_xZlKlA/-HhvKh5...
One use case is:
3) A guaranteed non-recursive way to access elements of parameter packs
and Doug Gregor (quoting from above post) says:
This is probably the most-requested feature for variadic templates, and it never it made it because we never found a good, unambiguous syntax.
The attached seems to do that. What about adding something like this to the library?
-regards, Larry
Attached is a solution that uses C++14 index sequence (which is recursive, afaik), but is otherwise recursion free. Maybe there is a non-recursive alternative to index_sequence to "eat up" the first N-1 elements? The code based on the third attachment of this clang bug report http://llvm.org/bugs/show_bug.cgi?id=13263 Regards, Roland
On 05/20/14 17:00, Roland Bock wrote:
On 2014-05-20 20:59, Larry Evans wrote:
On 05/18/14 15:41, Louis Dionne wrote:
Dear Boost,
A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11.
The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far.
Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is.
Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test.
As mentioned in this post:
https://groups.google.com/forum/?hl=en#!msg/comp.std.c++/_-6X_xZlKlA/-HhvKh5...
One use case is:
3) A guaranteed non-recursive way to access elements of parameter packs
and Doug Gregor (quoting from above post) says:
This is probably the most-requested feature for variadic templates, and it never it made it because we never found a good, unambiguous syntax.
The attached seems to do that. What about adding something like this to the library?
-regards, Larry
Attached is a solution that uses C++14 index sequence (which is recursive, afaik), but is otherwise recursion free. Maybe there is a non-recursive alternative to index_sequence to "eat up" the first N-1 elements?
The code based on the third attachment of this clang bug report http://llvm.org/bugs/show_bug.cgi?id=13263
Regards,
Roland
Thanks very much Roland. I had no idea there was this way to do it. However, I had a lot of trouble understanding how it worked; hence, I added a bunch of comments, as shown in the attached. After adding the comments, I now understand what you mean by "eat up" the first N-1 elements. -regards, Larry
On 2014-05-21 18:42, Larry Evans wrote:
On 05/20/14 17:00, Roland Bock wrote:
On 2014-05-20 20:59, Larry Evans wrote:
On 05/18/14 15:41, Louis Dionne wrote:
Dear Boost,
A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11.
The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far.
Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is.
Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test.
As mentioned in this post:
https://groups.google.com/forum/?hl=en#!msg/comp.std.c++/_-6X_xZlKlA/-HhvKh5...
One use case is:
3) A guaranteed non-recursive way to access elements of parameter packs
and Doug Gregor (quoting from above post) says:
This is probably the most-requested feature for variadic templates, and it never it made it because we never found a good, unambiguous syntax.
The attached seems to do that. What about adding something like this to the library?
-regards, Larry
Attached is a solution that uses C++14 index sequence (which is recursive, afaik), but is otherwise recursion free. Maybe there is a non-recursive alternative to index_sequence to "eat up" the first N-1 elements?
The code based on the third attachment of this clang bug report http://llvm.org/bugs/show_bug.cgi?id=13263
Regards,
Roland
Thanks very much Roland. I had no idea there was this way to do it. However, I had a lot of trouble understanding how it worked; hence, I added a bunch of comments, as shown in the attached. After adding the comments, I now understand what you mean by "eat up" the first N-1 elements.
-regards, Larry
It took me quite a while, too :-) I am having a few difficulties with the documentation in the places that use a '+1', especially here: "return (N+1)-th ts, where 0-th ts is first one." With N==0, you get the argument at position 0. The above sentence seems to be telling something different or am I just too tired? Other than that: good job at documenting. I probably would have tried to describe the concept instead of documenting the individual parts, but I find it quite hard to describe this in natural language. I'll give it some more thought, though :-) Best, Roland
On 2014-05-21 18:42, Larry Evans wrote:
On 05/20/14 17:00, Roland Bock wrote:
On 2014-05-20 20:59, Larry Evans wrote:
On 05/18/14 15:41, Louis Dionne wrote:
Dear Boost,
A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11.
The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far.
Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is.
Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test.
As mentioned in this post:
https://groups.google.com/forum/?hl=en#!msg/comp.std.c++/_-6X_xZlKlA/-HhvKh5...
One use case is:
3) A guaranteed non-recursive way to access elements of parameter packs
and Doug Gregor (quoting from above post) says:
This is probably the most-requested feature for variadic templates, and it never it made it because we never found a good, unambiguous syntax.
The attached seems to do that. What about adding something like this to the library?
-regards, Larry
Attached is a solution that uses C++14 index sequence (which is recursive, afaik), but is otherwise recursion free. Maybe there is a non-recursive alternative to index_sequence to "eat up" the first N-1 elements?
The code based on the third attachment of this clang bug report http://llvm.org/bugs/show_bug.cgi?id=13263
Regards,
Roland
Thanks very much Roland. I had no idea there was this way to do it. However, I had a lot of trouble understanding how it worked; hence, I added a bunch of comments, as shown in the attached. After adding the comments, I now understand what you mean by "eat up" the first N-1 elements.
-regards, Larry
It took me quite a while, too :-)
I am having a few difficulties with the documentation in the places that use a '+1', especially here:
"return (N+1)-th ts, where 0-th ts is first one." Yeah, you're right. I think the where clause should be removed. I spent 10-20 minutes trying to avoid the "off by 1"
On 05/21/14 16:30, Roland Bock wrote: problem, but apparently wasn't entirely successful. Thanks for the catch.
With N==0, you get the argument at position 0. The above sentence seems to be telling something different or am I just too tired?
Other than that: good job at documenting.
Thanks. I appreciate that.
I probably would have tried to describe the concept instead of documenting the individual parts, but I find it quite hard to describe this in natural language. I'll give it some more thought, though :-)
Best,
Roland
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 18.05.2014 22:41, Louis Dionne wrote:
Dear Boost,
A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11.
The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far.
Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress.
Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is.
Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test.
Roadmap ------- Finish exploring the design space. If it turns out that we can merge the MPL and Fusion, then I'll be working on that for a while. If I find that this is not possible or not a good idea, I'll go back to my initial GSoC planning. In both cases, I hope to have a library in the incubator by the end of the summer. Also, this new roadmap is approved by my mentor.
Feel free to reply with questions and/or comments.
Regards, Louis
[1]: http://ldionne.com/mpl11-cppnow-2014 [2]: http://github.com/ldionne/hana
As it seems you have chosen the name hana, I think it is not a good idea. There is a software product called SAP HANA (http://en.wikipedia.org/wiki/SAP_HANA) which may to lead to confusion and legal problems. I have to say I'm not a lawyer, but I think this problem should be addressed. Jan Herrmann
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Jan Herrmann Sent: 02 June 2014 17:09 To: boost@lists.boost.org Subject: Re: [boost] [GSoC][MPL11] Post C++Now update
On 18.05.2014 22:41, Louis Dionne wrote:
As it seems you have chosen the name hana, I think it is not a good idea. There is a software product called SAP HANA (http://en.wikipedia.org/wiki/SAP_HANA) which may to lead to confusion and legal problems. I have to say I'm not a lawyer, but I think this problem should be addressed.
It also fails the tradition that the name should at least hint to the user what the Boost library might do. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830
participants (15)
-
Agustín K-ballo Bergé -
David Stone -
Eric Niebler -
Gonzalo BG -
Hartmut Kaiser -
Jan Herrmann -
Joel de Guzman -
Larry Evans -
Lee Clagett -
Louis Dionne -
Matt Calabrese -
Paul A. Bristow -
paul Fultz -
Roland Bock -
Zach Laine