Boost logo

Boost :

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/



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk