[boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)

Subject: [boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-24 16:07:36

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/