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: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2015-05-26 06:40:56

On 26 May 2015 12:09 am, "Niall Douglas" <s_sourceforge_at_[hidden]> 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<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.

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<result<T>, result<T>*>.

> > 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/boost>lists.boost.org
<http://lists.boost.org/mailman/listinfo.cgi/boost>/mailman/
<http://lists.boost.org/mailman/listinfo.cgi/boost>listinfo.cgi
<http://lists.boost.org/mailman/listinfo.cgi/boost>/boost
<http://lists.boost.org/mailman/listinfo.cgi/boost>