On 19 Jun 2015 at 10:50, Robert Ramey wrote:
On 6/19/15 10:03 AM, Niall Douglas wrote:
https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Boost.S pinlock%20Test%20Linux%20GCC%204.8/doxygen/classboost_1_1spinlock_1_1l ightweight__futures_1_1monad.html
I didn't follow any previous discussion but out of curiosity I took a look at the documentation. I didn't see any information describing what this thing is, or what problem it solves. So to actually evaluate this, I'd have to ... I'm not sure. I think you'd like get more and better feedback if you included this information.
I do apologise. I thought the need for a C++ monad obvious. Some quick notes on this: Definitely read this before all the others: http://bartoszmilewski.com/2011/07/11/monads-in-c/ Constraint programming with monads: http://bartoszmilewski.com/2015/05/11/using-monads-in-c-to-solve-const raints-1-the-list-monad/ Tutorial in C++ monads: http://thebytekitchen.com/2014/10/22/harder-to-c-monads-for-mortals-1/ Combining tuples with monads (this is exactly what Hana is meant to help with): http://cpptruths.blogspot.ie/2014/08/fun-with-lambdas-c14-style-part-3 .html My own personal and particular need for a monad in AFIO: https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:S tronglyconsiderusingconstexprsemanticwrappertransporttypestoreturnstat esfromfunctions Many, many people have had a try at a C++ monad, including at least half a dozen people on this list and the one which came closest to standardisation was probably Vicente's Expected<T, E>. All those implementations have not caught on as the default monad for C++ for varying reasons. I have badly needed one for AFIO since its beginning as it solves a large number of design problems for me (the Handbook example is but one of many), but I made do without mainly because of MSVC. VS2015 is finally just about capable enough at C++ 11 to make a decent optimally lightweight C++ monad feasible, so here is my attempt. The main differences in mine over the other monads around are: 1. Monadic impurity. Mine is deliberately impure monad to make C++ programming much easier. A "C++-ised" monad. It also replaces optional<T> for me whose design I have never much liked mainly because optional<T> should always have been a monad like this one. 2. Fixed function. Mine hardcodes the unexpected options. This makes it easier to program against because you can switch on implicit conversions all the time, plus you can do polymorphic continuations like I have which I personally think is very cool. It also allows the compiler to generate far more optimal code some of the time because I've intentionally twiddled the compiler to not bail out during optimisation, so you don't get as much of the bloat traditional monads force the compiler to generate. 3. Standalone: Mine doesn't come with an associated library. It is completely standalone and single purpose. You can just drop it into projects and get to work. 4. Deep integration with future-promise. I'll demonstrate how handy this is when I bring lightweight future-promise for review to this list sometime in the next few weeks. Finally, you may still wonder as to the point? If you do some programming in Rust which will probably become C++'s biggest competitor five years from now, all Rust's error handling is done via its Optional type Option<T> and its Monad type Result<T, E> as there is no exception throwing mechanism in Rust whatsoever. Once you get used to programming and designing your code that way, you start to wish you could do the same as easily in C++. Rust's Option<T> and Result<T, E> are very lightweight on both build times and runtime overhead unlike most C++ monad implementations. With this proposed lightweight monad<T>, I very substantially close that gap between C++ and Rust, and I personally think my monad<T> is much nicer again to program against than Rust's which is a bit clunky. This may prove very useful in the years to come when C++ will be forced to get out of its ivory tower to stay relevant as a systems programming language as Rust starts to eat away at the C++ ecosystem. Does this help Robert? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/