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: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2015-08-24 19:02:56

On Mon, Aug 24, 2015 at 9:07 PM, 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.
>
>> 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++.
>

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

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

-- gpd

[1] I'm using 'type' loosely here to include class templates.
[2] It really it should be the File IO Monad as 'asynchronous' is more
of an implementation detail, but I'll leave this for the review.