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

Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Sam Kellett (samkellett_at_[hidden])
Date: 2015-08-24 12:59:25

On 24 August 2015 at 17:43, Niall Douglas <s_sourceforge_at_[hidden]> wrote:

> 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?