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

Subject: Re: [boost] [next gen futures] Lightweight monad ready for inspection
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-06-21 04:42:59

Le 21/06/15 09:07, Vicente J. Botet Escriba a écrit :
> Le 19/06/15 19:03, Niall Douglas a écrit :
>> Some may remember the thread starting from
>> http://boost.2283326.n4.nabble.com/next-gen-future-promise-What-to-cal
>> l-the-monadic-return-type-td4676039.html and that I would firstly
>> prepare an optimally lightweight monad<T> for review here before
>> going on to base a next-gen lightweight future-promise on that
>> monad<T>.
>
>
>
>
A few additional questions:

* The future::then function has the semantic of calling the continuation 
when the future becomes ready. In addition the future::then moved the 
future to the continuation.

I believe that your monad<T>::then has not this semantic. So, what is 
the added value of this function? IIUC, the difference between

     m.then(f);

and

     f(m);

is that monad::then wraps the result of f if needed as bind do, but the 
continuation function takes a monad reference

I believe that it would be better to have a different name. What a bout 
next, wrap_call, call_with, ...?

* As you have bind, why you don't have catch_error? I understand that 
::then could be used instead, but I would add it just for symmetry and 
because the user don't needs to check when she is handling errors.

* What about having a match function using overload on the stored type? [1]

* Monads are defined by having a bind and unit functions. I'm missing a 
unit function. std::future has std::make_future_ready, expected has 
make_expected, std::optional has std::make_optional.

I've been working on a generic make factory library [2] that could be 
associated to the unit Monad function

Vicente

[1] https://github.com/viboes/tags/tree/master/doc/proposals/match
[2] https://github.com/viboes/std-make/tree/master/doc/proposal/factories