Re: [boost] [next gen future-promise] What to call the monadicreturn type?

Subject: Re: [boost] [next gen future-promise] What to call the monadicreturn type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-26 10:28:27

On 26 May 2015 at 11:40, Giovanni Piero Deretta wrote:

> > For me my main purpose is making AFIO allocate four malloc/frees per
> > op instead of eight. I also make heavy use of make_ready_future(),
> > and by definition that is now optimally fast.
> 
> The ready future path is taken unconditionally or with a condition often
> known at compile time? If yes that seems strange to me and would love to
> see an example. If no then you are probably optimising for the wrong case.

If an op is scheduled with a precondition which has already 
completed, a make_ready_future is scheduled to be executed on 
function exit that makes the outcome the same as if the precondition 
were continued. That happens a good chunk of the time.

> > Also, as I mentioned, the lion's share of the future implementation
> > is actually reusable as a monadic transport. That's currently a
> > monad<T, consuming> base class in my code, but I am asking for bike
> > shedding here on what to name a user facing specialisation.
> >
> 
> I think you are selling your code wrongly. What you have is a potentially
> zero overhead expected-like result wrapper; this is something people would
> want. What you are advertising is a zero overhead future in the
> uninteresting case and people can't see the point of it.

TBH I don't really care about what other people *think* they want. 
Most of the time what people think they want before they *need* it is 
misplaced. I've seen that already in some of the comments here, 
people are bikeshedding what they think a future/expected/monad ought 
to be without actually needing a better future/expected/monad for 
their specific problem use case.

I *do* have a pressing use case, and better futures makes my 
immediate pressing use case go away. I've been working on the correct 
redesign since October 2014, so none of these design decisions were 
taken without very ample reflection. I also waited to attend Thomas 
Heller's C++ Now presentation on his replacement futures before 
starting my own. I think my solution to my problems solves all the 
major problems ASIO has with futures too, as my problems are those 
also of ASIO. That could eventually help bridge the travesty the 
Networking TS is currently being degraded into :(

That may mean this design could be useful in Boost.Thread too, and 
therefore eventual standardisation as part of repairing the 
Networking TS for the next standard release after they no doubt cock 
up the first attempt. We'll see.

> The fact that your future is internally implemented using your result
> wrapper is nice but not critical.

It *is* critical if you want a future to efficiently convert into a 
result, and vice versa.

> Also why does the future inherit from the result object? I would expect it
> to contain something like variant<result<T>, result<T>*>.

It won't inherit from result, but from the same base class (currently 
"monad"). No variants at all in this design (too expensive).

> > > I believe that trying to design a future that can fulfill everybody's
> > > requirements is a lost cause. The c++ way is to define concepts and
> > > algorithms that work on concepts. The types we want to generalize are
> > > std::future, expected, possibly optional and all the other futures that
> have
> > > been cropping up in the meantime. The algorithms are of course those
> > > required for composition: then, when_all, when_any plus probably get and
> > > wait.
> >
> > I think it might not be a lost cause in a world with concepts and
> > especially modules. Until then it's going to be unacceptably slow.
> 
> I'm not following. How do concepts and modules allows to have a catch all
> future?

If we had C++ Modules and Concepts now, my guess would be that 
Expected would be enormously faster to build. Of course, we'd simply 
push out the complexity still further until even Modules wasn't 
enough. GCC will be in the way of ubiquitous Modules though :(

> If you need this week just use boost.thread future and get afio reviewed
> with that. Have the magic future as an optional unstable preview only
> interface.

AFIO already uses either boost::future or std::future. Has done since 
v0.1. Indeed Vicente patched extra APIs into boost::future for me to 
improve performance :)

But the community here said they wanted a "final" API before review, 
so I'll deliver exactly that. These futures will be custom subclassed 
by AFIO into a special afio::future, and that makes a ton of API 
cruft dealing with the limitations of std::future go away.

> Boost reviews usually focus on interfaces more than implementation. As long
> as the reviewers believe that your interface can be implemented efficiently
> you'll be fine.
> 
> In fact having yet another non interoperable future in afio might be a
> negative point during review.
> 
> After afio is accepted,  you can lobby to get boost.thread future do what
> you want, or better add generalised future composition to boost.

c.f. earlier discussion here asking for community preferences. tl;dr; 
the community prefers a "final" API to review. They shall get it.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/