Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-28 06:29:07
On 28 May 2015 at 8:00, Vicente J. Botet Escriba wrote:
> >> 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.
> In other words, beside the slow compile time of expected, what you don't
> need from expected?
I would prefer to not have to think when writing code with expected.
I think a monadic return type should be so primitive as to require no
thought in usage even for the completely unfamiliar.
This is why I borrow the API and semantics from future for the monad.
> I see that you want to be able to store error_code or exception_ptr.
> Wouldn't the interface of expected<T, variant<error_code,
> exception_ptr>> be enough?
One of the big attractions for me to the fixed variant design is
implicit conversion from T, error_code and exception_ptr. No extra
typing. No extra thought. Just return what you mean from a function,
and let the compiler sort it out.
> > ... and another table showing the progression from minimal monad to
> > maximum monad.
>
> I believe that we should stop using the word monad in this way. Just
> wondering what would be the operations of these monads.
> I'm aware of the operations of a Monad and the operations of an Error
> Monad. I'm aware of the operations of a Functor, an Applicative, ....
> These operations have nothing to be with the operations the concrete
> type provides.
I do agree - a monad is a monad or else it is not.
Ok, I am being fuzzy now, but my feelings - rather than opinion -
about Expected was it is too monolithic somehow. It's like this big
thing when I don't want a big thing, at least not usually. I want
Expected to be a programming primitive, and it never felt to me it
was a primitive.
I am sorry I am not much help here. Perhaps Lee can help? He had a
different opinion of using Expected in big code bases to me.
> My question was about the "to be named" type. Would this type be visible
> on the AFIO interface?
Yes. As a custom afio::future<T>. Users will notice they can't feed
those futures into normal when_all/when_any.
> I don't know nothing at all about AFIO, but why the following is not
> good for you, then?
>
> template <class T>
> using your_name = future<tuple<async_io_handle, T>>;
I unfortunately need to carry more state than this. I suspect I am
not the first to have this problem with futures, hence my desire for
a lightweight future library easily extended with custom future
types.
> > 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.
> >
> Yes, I'm aware of the difficulty. Any help to make it more robust is
> welcome. As I said in another thread (Do we can a non backward
> compatible version with non-blocking futures?), I was working on a
> branch for non-blocking futures and a branch for lightweight executors.
> I must take the time to merge both together.
Up until now I have had the enormous advantage over you of being able
to assume that there is an ASIO available to push work onto. That
makes my implementation far easier, because when I need to tie break
I just defer work onto ASIO.
That said, I'm going to attempt an executor-less implementation this
time round. We'll see how it goes.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/