Boost logo

Boost :

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

On 27 May 2015 at 7:02, Vicente J. Botet Escriba wrote:

> >> So the question is, do we have the proposed interface for expected, or
> >> something else?
> >> Would be the 'to be named type" a literal type?
> > I would far prefer if Expected were layered with increasing amounts
> > of complexity, so you only pay for what you use.
> >
> > I also think you need to await the WG21 variant design to become
> > close to completion. It makes no sense to have an Expected not using
> > that variant implementation, you're just duplicating work.
> My apologies. No seriously, this are implementation details. Could you
> describe the interface changes that expected need.

That's a huge question Vicente. And it's very hard to answer in
detail, because I don't really know.

I don't think variant is an implementation detail. I suspect people
will want to explicitly convert from an ordered variant into an
expected and vice versa for example. They will also want to "repack"
a variant from one ordering of type options into another without
actually copying around any data.

I can also see a Hana heterogeneous sequence or std::tuple being
reduced into variant and/or into an expected. And so on.

Until all this ecosystem stuff becomes more final, it is hard to
imagine a new expected interface.

> > Other than that, I found the interface generally good. I only ever
> > needed about 10% of it personally, but it would be nice if the
> > remainder were available by switching it on maybe with an explicit
> > conversion to a more intricate subclass. The more intricate subclass
> > would of course live in a separate header. Pay only for what you use.
> >
> >
> Could we define this interface?

If I remember rightly, in your WG21 paper you had a table somewhere
where you compared futures to optional to expected with a tick list
of features shared and features not shared.

I think you need an orthogonal table of:

1. Lightweight monad.
2. Intermediate monad.
3. Featureful monad.

... and another table showing the progression from minimal monad to
maximum monad.

If you examine
lock/future.hpp you should see that monad<>, from which future<>
derives, implements simple then(), bind() and map(). future<> only
implements then(), but I am planning for it to allow a then(F(monad))
which would allow future to also provide bind() and map().

My idea is you can eventually switch freely between asynchronous
monadic programming and synchronous monadic programming using a
simple cast, so I am implementing a "two layer" monad where the first
is a synchronous monad and the second is an asynchronous monad. But
I'm a long way away from any of that right now.

> In other words, would the "to be named" type appear on the AFIO
> interface? Is for this reason that you need to name it? or it is really an
> implementation detail. This merits clarification.

Right now AFIO's synchronisation object is a struct async_io_op which
contains a shared_future<shared_ptr<async_io_handle>>.

I'm going to replace async_io_op with a custom afio::future<T> which
*always* carries a shared_ptr<async_io_handle> plus some T (or void).
Internally that converts into a future<tuple<async_io_handle, T>> but
that isn't important to know.

That custom afio::future<T> will subclass the lightweight future<T> I
am currently building.

Strictly speaking, there is nothing stopping me building the same
custom afio::future<T> right now using std::shared_future. However, I
would need to implement continuations via .then(), and if I am to
bother with that, I might as well do the whole lightweight future
because as you know from Boost.Thread, most of the tricky hard to not
deadlock work is in the continuations implementation.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at