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

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 
https://github.com/ned14/boost.spinlock/blob/master/include/boost/spin
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.

Niall

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