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: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-08-25 10:23:40

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Andrey Semashev
> Sent: 25 August 2015 15:12
> To: boost_at_[hidden]
> Subject: Re: [boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)
> 
> On Tue, Aug 25, 2015 at 3:44 PM, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> > On 25 Aug 2015 at 0:02, Giovanni Piero Deretta wrote:
> >
> >> > It's a C++ monad designed for C++ programmers writing in C++.
> >>
> >> Niall, you are missing the point: the reason that your monad can't be
> >> the true definition of a Monad is that no type can.
> >
> > No, that's exactly why I chose that name for the library. I absolutely
> > get the point.
> >
> >> That there is no
> >> such a thing as Monad type in Haskell at all; there is a type *class*
> >> named Monad.  In Haskell there are many concrete types that are
> >> instances of the Monad type class (list, Maybe, IO). Other languages
> >> are similar: I believe you are familiar with rust, in that language
> >> Monad would be a trait.
> >>
> >> Similarly, in C++ you can have multiple types[1] (option, future,
> >> etc...) that model the Monad concept (Haskell type classes loosely
> >> map to C++ concepts), but calling any of them (or a template type) a
> >> Monad, makes at much sense as having a class named RegularType.
> >
> > Again, exactly why I chose it: it makes no sense.
> >
> >> In C++, you could argue that 'monad' would be a decent name for type
> >> erased wrapper over any type that model the Monad concept, but I do
> >> not believe that your monad type is that.
> >>
> >> Now, afio::monad, while not great, at least suggests that we are
> >> talking about the Monad of Asynchronous File IO [2].
> >
> > C++ is not a functional programming language and never will be, and I
> > even think nor should it be.
> >
> > I certainly don't get anything like as worked up about naming as
> > people are getting over this. Who cares if it doesn't pollute
> > namespace, is short to type and isn't going to get confused with
> > something else?
> >
> > That's why value<T> or holder<T> or return_<T> all got ruled out.
> > They will confuse. monad<T> is nonsense name, but it stands out nicely
> > in code and let's the eye quickly check that your logic is correct.
> >
> > As monad<T>'s main use case for me so far at least is exception safety
> > management, it NEEDS to stand out from surrounding code as a return
> > type from a function.
> >
> > But let me clear, if anyone can suggest a similarly short, instantly
> > recognisable, uniquely standout name for monad<T>, I'm all ears.
> >
> > For example, I have toyed with donkey<T> instead of monad<T>. Also a
> > nonsense name, but it does the donkey work of exception safety for you
> > (with monadic programming extensions) and it has all the features of
> > standing out from surrounding code, being quick to type and so on.
> >
> > Would people prefer Boost.Monad => Boost.Donkey, and monad<T> =>
> > donkey<T>?
> >
> > The reason I didn't choose donkey<T> is because I thought people
> > wouldn't take a Boost.Donkey library seriously, and that would be a
> > shame as I'm finding it an enormous productivity aid. It also doesn't
> > fit to have a lightweight fast Concurrency TS implementation in a
> > library called Boost.Donkey.
> >
> > But I also don't think the naming war on this library can be won. If
> > Boost.Donkey will stop the war and make people vote for acceptance,
> > I'll take Boost.Donkey over Boost.Monad any day.
> 
> I don't know Haskell or what monad means there, so to me monad<> does not stand out, apart from
> that I don't know what it means. That's probably because there are lots of things that I don't
know or
> understand, so there's nothing special about it. :)
> 
> However, reading your argument I don't see the rationale behind choosing the name which overloads
> what apparently is a well understood term in Haskell. If the meaning of your monad<> differs from
> that well established understanding then this will certainly lead to confusion and endless
questions
> and notes like 'that C++ monad is not the monad you know'. To me this indicates that the naming
> choice is poor.
> 
> So my point is name it donkey, if you feel this name reflects the component purpose well (I doubt
it).
> Pick another name that is not overloaded yet or has close semantics. Only keep monad if it doesn't
> cause confusion.

Absolutely right.

Anything but monad!  It *does* cause confusion.

Think again -  and donkey won't do either ;-)

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]