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 09:05:51

On 28 May 2015 at 14:38, Peter Dimov wrote:

> > 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?
> 
> future<T> already adds the ability to store exception_ptr. There is no need 
> to store another exception_ptr in the value. Niall's type is exactly 
> equivalent to future<expected<T, error_code>>, as I already said (twice).

exception_ptr unfortunately must always do an atomic write to memory. 
That always forces code to be generated, and very substantially 
reduces optimisation opportunities because state must be reloaded 
around the exception_ptr.

This, and the mandatory memory allocation, is a big reason current 
futures are not suitable for high performance ASIO.

I also want a big semantic change that error returns are not 
exceptional. We hugely underuse std::error_code in STL C++ 
unfortunately. I am not one of those people who believes exceptions 
are evil, and ban them in the language as all the new system 
languages seem to. I also have no love for forcing everything through 
the return code as with C and Rust, but I do think there is a middle 
ground between good outcomes, bad outcomes, and exceptional outcomes 
which is easy to program, easy to conceptualise, and easy on the 
compiler.

I therefore think some mongrel impure future/monad/optional type 
might just be the ticket. But I think I need to deliver real code 
used in a real world library to demonstrate its effectiveness first. 
If I don't persuade people of that simple effectiveness, then 
somebody else's solution is better.

> > I proposed to the C++ standard a function future<T>::next (bind) that 
> > takes a continuation having T as parameter (future<R>(T)), and and 
> > future<T>::catch_error that takes a as parameter a continuation that takes 
> > an errror as parameter. The proposal was not accepted.
> 
> future<T>::next( [](T){...} ) is actually pretty useful, catch_error() much 
> less so. You should have proposed just the former. (Sean Parent's future 
> implementation's ::then has ::next's semantics IIRC.) 

I was going to have my continuations specialise on their parameter 
type, so a continuation might take T, error_code, exception_ptr, 
monad<T>, future<T> as consuming continuations. To make those 
non-consuming continuations simply make those a const lvalue ref.

My only worry really on that feature is on compile times, so I may 
yet strip some of the automatedness. Also if I'm not going to 
regularly use a feature, then I'm removing that feature, I am aiming 
for a least possible implementation. We'll see how it goes.

Niall

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