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-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/