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. Robert Ramey