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

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

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/