Re: [boost] [next gen futures] Lightweight monad ready for inspection

Subject: Re: [boost] [next gen futures] Lightweight monad ready for inspection
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-19 15:52:08

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/