On 24 August 2015 at 18:21, Robert Ramey
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.