On 24 Aug 2015 at 19:21, Peter Dimov wrote:
I have to say that I find this choice of naming baffling. Why would you name a concrete type 'monad'? Makes no sense to me.
That was discussed on this very list in great depth and length. The choice of monad<T> was made to ensure people looked up the documentation for what it meant instead of making any assumptions. I think that aim worked out beautifully.
Would not something like afio::result been better? In this way this is clearly a part of AFIO and no separate review would be necessary.
In Monad in addition to a monad<T> there is a result<T> and an option<T> in increasing order of lightweightness. They all specialise basic_monad<>.
If one insists on calling a type boost::monad, this is a serious claim over quite a territory and I agree with Andrey that this calls for a review of Boost.Monad.
It's coming in 2016. I am rewriting the AFIO engine first using Monad throughout, as that will debug Monad and put production ready finish on Monad. Then I'll have to write tutorials and docs and explain my design choices as I'm sure few will agree with them. For reference, it's boost::monad::monad<T>, not boost::monad<T>. And Monad specifically disclaims trying to be a full fat Haskell type monad in C++, it is a lightweight C++-centric monad with almost zero overhead. In my own code to date I have been finding it *amazingly* useful, my productivity has jumped and my debugging and unit test writing time cut significantly. I genuinely suspect I will never write C++ code without using Monad or something very similar ever again. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/