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/