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

On 26 May 2015 12:09 am, "Niall Douglas" wrote:

Giovanni Piero Deretta wrote:

...

So, the future/promise pair can be optimized out if the work can be completed synchronously (i.e. immediately or at get time). But then, why use a future at all? What is the use case you are trying to optimize for? do you have an example?

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.

Also, as I mentioned, the lion's share of the future implementation is actually reusable as a monadic transport. That's currently a monad 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. The fact that your future is internally implemented using your result wrapper is nice but not critical. Also why does the future inherit from the result object? I would expect it to contain something like variant.

...

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?

And that's years away, and I need this now.

Regarding heterogeneous future type wait composition, yes this is hoped to be the foundation for such an eventual outcome. That's more Vicente's boat than mine though.

...

We could just take a page from Haskell and call the concept Monad, but maybe we want something more specific, like Result.

I'll take that as a vote for result<T>.

Eh, I meant it as a concept name, not actual class, but sure.

Bjorn suggested holder<T> and value<T> as well. I think the former too generic, and the latter suggests the thing is a value and can decay into one without get(). Or maybe, that some might think that.

You could leave the return type unspecified and just list the type requirements.

...

Then, in addition to the algorithms themselves, there is certainly space in boost for a library for helping build custom futures, a-la boost.iterator.

I originally intended that, my second round of experiments showed it could be very exciting. But I choose to bow out in favour of something I can deliver in weeks rather than months. I need all this ready mid-June so I can start retrofitting AFIO.

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

Besides, simpler I think may well win the race. More complex means more compiler quirks. I am dealing enough with those already!

Niall

-- ned Productions Limited Consulting http:// http://www.nedproductions.biz/www.nedproductions.biz/

http://www.nedproductions.biz/

http:// http://ie.linkedin.com/in/nialldouglas/ie.linkedin.com http://ie.linkedin.com/in/nialldouglas//in/ http://ie.linkedin.com/in/nialldouglas/nialldouglas http://ie.linkedin.com/in/nialldouglas// http://ie.linkedin.com/in/nialldouglas/

_______________________________________________ Unsubscribe & other changes: http:// http://lists.boost.org/mailman/listinfo.cgi/boostlists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost/mailman/ http://lists.boost.org/mailman/listinfo.cgi/boostlistinfo.cgi http://lists.boost.org/mailman/listinfo.cgi/boost/boost http://lists.boost.org/mailman/listinfo.cgi/boost