Re: [boost] Final lightweight monad, next gen futures and upcoming AFIO review (was: Re: [next gen futures] Lightweight monad r

Subject: Re: [boost] Final lightweight monad, next gen futures and upcoming AFIO review (was: Re: [next gen futures] Lightweight monad r
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-29 06:04:34

On 28 Jun 2015 at 17:52, Vinícius dos Santos Oliveira wrote:

> > monad<T>, result<T> and option<T> are all *synchronous* value
> > transports. Just like Rust's Result and Option.
> 
> So, why can result<t> be empty?

The idea was that the synchronous transport editions map semantically 
onto the asynchronous transport editions. So:

Empty <= Unsignalled/Default constructed.
Value <= Value.
Errored/Excepted <= Errored/Excepted.

If you consider a default constructed future, you will see you have 
to have a default constructed monad be empty. What else could it be?

There is also the truth that allowing an empty state makes everything 
vastly more efficient to implement. For example, I can hard assume 
that monad<T> will always have a default constructor, and that makes 
implementing monad<monad<T>> considerably easier. If an exception 
throws during a move or copy constructor, I can throw the exception 
out with the monad left empty. In a situation with (de)serialisation, 
the ability to guarantee default construction no matter what T is is 
also very valuable. All this turns into a minimum number of assembler 
instructions output by the compiler, and is why I chose this design.

> I mean: result<T, E> is like "give me T or it's an error". There is no
> empty state. Empty would already be an error state. I'd only understand
> empty if it's an async operation that didn't finish already.

In case others on boost-dev don't realise, Vinicius here is referring 
to Rust, not C++. Myself and Vinicius currently work for the same 
client writing code in Rust, at least until he replaces me in a few 
week's time! :)

Rust's Result<T, E>, and any traditional monad, has no empty state. I 
would call those "pure monads". My monad is not a pure monad, it is a 
"dirty" monad with an impure design which I hope/believe is better 
suited to the typical C++ programmer. For example, monadic parsing is 
not well suited to my impure design, it does work if you throw an 
exception to carry the failure to parse state so it "works", but 
nobody should be doing that in any real world code.

I may be wrong in those design tradeoffs and assumptions - just 
because I've been working on the right design for over a year (I have 
a presentation I did on these design deliberations February 2014 with 
many of the same unsolved problems) doesn't mean I am 100% confident 
in it being the correct balance between all the exigencies.

However, the AFIO review is in two weeks, and boost-dev wanted a 
final AFIO design, so here it is coming best as I can make it.

Niall

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