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
> > > 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
> > 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
> > 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
> > the word monad and the namespace boost::monad seems to be a bit scary
> > 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>
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>
// 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk