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 13:59:06

On 24 August 2015 at 18:21, Robert Ramey <ramey_at_[hidden]> wrote:

> On 8/24/15 9:59 AM, Sam Kellett wrote:
>
>> 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.
>>
>
> I have personal experience with this problem.  As I mentioned before, when
> I made the boost serialization library.  I included things like
> state_saver, singleton, etc in the boost namespace.  No one objected
> through two reviews - but I eventually caught hell for this and ended up
> moving to the namespace boost::serialization.  (boost was a rougher
> environment in those days).  Seems to be an implicit but long running
> consensus that only those components which have passed formal review should
> be inserted directly into the boost namespace.  I would agree with this
> idea.
>
> I raised a few concerns about the "monad" "library" when it was first
> discussed on the list and never really bought into it as a boost library
> (as constituted) and don't think it should be included now.  Though I'm
> skeptical of Niall's monad, I've got not complaint if Nail want's to make
> boost::afio::monad and later try to get it "promoted" to boost::monad.
> Doing this would demote Niall's monad to the status of implementation
> detail or private API and hence wouldn't irrevocably occupy any coveted
> territory.  It would also make the review of AFIO much easier and more
> likely to pass.  It would also be an easy change for Niall to (promise to)
> make.
>

that seems to be a nicer way to go about it.

i've played with the idea in my head for the past half an hour and i think
i would quite like boost::monad to be maybe a few customisation points:
bind, return, fail, even >> and >>= (although i would imagine associativity
and precedence would get in the way of the last two) that your own
monadic-like classes could specialise and then use as first class monads.
this is maybe getting a bit off topic now so i'll stop.