Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-24 12:43:23

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/