-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
should we add meta continuations to brigand? #242
Comments
uh scratch that I found a trick to get everything except for multi list transform to work on MSVC2015! |
That's awesome. I'm going to do a couple of changes to the directory structure this week end to prepare the Boost submission. |
how far along is the boost submission? is there enough time for a major change like adding continuations? I really would like to have continuations in boost in some way shape or form and I think it might tip the scale in our favor. Maybe I should make a branch which tackles the low hanging fruit like algorithms with no predicates (insert, erase, at, reverse etc.) so the other contributors here can get a feeling for it. |
I think you have time. We have a lot of work documentation-wise. |
What are meta continuations?
The basic concept is that rather than having templated structs which contain both algorithm and the data being worked one uses a templated struct for the algorithms only which provides a nested template which works on the data. This pattern allows for better memoization of algorithms and faster work on data due to passing by alias rather than instantiating a type.
Advantages:
Algorithms can be composed at zero cost. In fact since we can make optimizations to composed algorithms, for example when unpacking the same list twice as is the case in partition. The ability to compose algorithms in this way allows for many more algorithms to be implemented in terms of other algorithms.
For example the algorithm filter is just a transform and then a join and then a "listify" (listify is a contination which makes a list from the input parameters) but if we swap out the last step with a "count" (count is a continuation wrapper around sizeof...(Ts)) then we have a count_if. This kind of composition would be far slower with other paradigms than the hand written equivalent count_if but with continuation style this becomes a viable solution.
The real advantage I see is that the user profits from this composability as well. Initial use of this in kvasir::bit has shown that the ability to compose arbitrary algorithms can make a 10 fold improvement in the speed of complex calculations.
Disadvantages:
Although this pattern does work on clang 3.0+ GCC 4.7+ and MSVC2017 I just can't get it to work on MSVC2015.
Surprisingly I can't think of anything which would be broken if we swapped out all of brigands guts for kvasir::mpl's guts (basically everything in namespace mpl::c). We can implement brigands sequence type agnostic behavior easily since kvasir::mpl does not use any lists under the hood in most algorithms any way and the last listification step could be configured to be the type of the sequence which brigands front end matched. Brigand lambdas could also be wrapped up in a continuation and just work as a predicate in kvasir::mpl algorithms.
That being said I've been coding too long to believe there will not be some weird shit that only comes to light after we are 90% done with porting.
The text was updated successfully, but these errors were encountered: