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
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 http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk