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. 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 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 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/
