On 24 August 2015 at 17:43, Niall Douglas
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.
i'm sorry i missed the other thread, i've only been following boost-dev for a couple of months so sorry if i'm repeating what's already been said but this doesn't feel version user friendly. and although i get the intention if you're going to do that maybe you should make up a new word entirely. that way nobody knows what it means as opposed to this where some people may mistakenly think it means what monad is supposed to mean where here it doesn't quite (i think!).
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.
i think the main issue i have over this is (unless totally mistaken) that boost::monad::monad<T> is not true to the definition of a monad. it is, like mentioned earlier, more akin to an expected/optional monad. so taking the word monad and the namespace boost::monad seems to be a bit scary when in the future they could be used for a totally generic full fat haskell type monad in c++ as you say. perhaps boost::afio::monad?