On 24 Aug 2015 at 17:59, Sam Kellett 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!).
Naming of fundamental C++ primitive types is always guaranteed to lead to never ending debate here (and at WG21 for that matter). You can check the history of this list for the discussion which has plenty of names suggested. I chose monad<T>, result<T> and option<T> out of the many, many options suggested. Most people will disagree with those choices, and no matter what names I choose it would still be the case that most people will disagree with anything I chose. Such is naming C++ fundamental objects.
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.
This is incorrect. It does have the full power of a monad if you use exception throws as an erased type transport. Which is of course insane and has awful performance, so you shouldn't do that. You're right in the ordinary sane use case it's not a Haskell monad. It's a C++ monad designed for C++ programmers writing in C++.
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.
Personally speaking I would doubt there will ever be a full fat haskell type monad in common C++ programming. The cost benefit isn't there for C++ 14 or C++ 1z as it is currently defined. There has been a big trend towards simpler, less compile time heavy library primitives in recent years, and until I am proven wrong that rules out full fat Haskell type monads in C++. Maybe some future C++ language edition with much improved tooling might make it work, but that's a 2020s thing minimum. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/