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

Subject: Re: [boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)
From: Sam Kellett (samkellett_at_[hidden])
Date: 2015-08-24 19:41:48

On 24 August 2015 at 21:07, Niall Douglas <s_sourceforge_at_[hidden]> wrote:

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

for sure, but isn't using 'monad' putting fuel on that fire? it's like
calling vector 'container'.

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

i'm not sure i see where the complexity comes from. what i would like to
see would be a bind function like so:

template <template <typename> class M, typename A, typename B>
M<B> bind(M<A>, std::function<M<B>(A)>);

and a return like so:

template <template <typename> class M, typename A>
M<A> return_(A);

then the operator >> could be implemented in terms of bind and then i am
free to provide partial specialisations for bind and return_ to be able to
use the >> operator with my type.

so something like:

template <typename A, typename B>
boost::optional<B> bind(boost::optional<A>,
std::function<boost::optional<B>(A)>)
{
  // ...
}

// ditto for return_

et voila, boost::optional is now a monad.

beyond that basic level you could then incorperate more of haskell's
monadness with monadplus and fmap, etc... in a similar generic manner

standard disclaimer: it's late and i haven't run any of this so almost
certainly contains errors as is.. but i hope the idea of what i'm getting
at shines through nonetheless.