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

Subject: Re: [boost] Final lightweight monad, next gen futures and upcoming AFIO review
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-29 07:58:46

On 29 Jun 2015 at 13:29, Andrzej Krzemienski wrote:

> > > If "empty" means something different in the case of three-type "result",
> > > perhaps it deserves a different name?
> >
> > In my synchronous monad, empty is always an invalid state, just as
> > with future.
> >
> 
> In that case, perhaps name "empty" is not the best choice? It has positive
> connotations like "empty optional" or "empty vector" which are as valid
> states as only a state can be. I believe "invalid state" would reflect your
> intention more clearly.

It's a tricky one this. On the one hand, empty means that 
get()/get_error()/get_exception() will throw no_state, so in that 
sense it is invalid.

On the other hand, the monadic operators bind/map/next etc see empty 
as a valid state i.e. you can write the bind expression:

monad<T> >> [](monad<T>::empty_type) { /* executed if empty */ );

... and that's just fine too. Similarly, the AND OR operators treat 
empty as equal to errored/excepted, so:

monad<int> & 5 | 2

... means that if the monad has a value, emit a monad with 5, else 
emit a monad with 2.

Finally, the specialisation option<T> (which is simply a monad 
missing the ability to be errored or excepted) has only the two state 
options of empty or T. Otherwise it's a monad in every other way, and 
can interact with monads like result or monad (i.e. option<T> will 
implicitly convert to monad<T>, and monad<T> can be explicitly 
converted to option<T>). For option<T>, an empty state might be 
invalid, but it is also valid in the sense of state being not a T. If 
that makes sense.

In other words, my "dirty monad" doesn't just act like a future, it 
also acts like an optional. Identical semantics. Your big win of 
choosing option<T> over monad<T> is far lighter weight overheads on 
runtime because exception_ptr is *expensive* when you are working in 
hundreds of cycles.

I can see already that all this ambiguity and lack of clear design 
goals will smack of a poor design not fully baked and thought 
through. I can assure boost-dev that I have been pondering this 
design for over a year and half a dozen designs were considered and 
thrown away before I settled on this design. So far, I am pleased 
with it as it ticks all the "red boxes" i.e. the absolute hard red 
line requirements I needed (specifically a minimal runtime and build 
time overhead). The rest of the design has been allowed to float to 
wherever it falls naturally, and you can see what we've now got - a 
real "mongrel" of a design where it is up to the programmer to not 
shoot themselves in the foot.

This is not to say I don't have qualms and concerns and worries with 
this design. All I am claiming is that it solves my pressing problems 
in what I think is a neat way, and I am therefore pleased with it so 
far. I may later discover I have made a serious design boo boo.

Thanks everyone for your feedback. Designing this stuff is hard, and 
your comments have been very useful and helpful.

Niall

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