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
> 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 (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 .
 I'm using 'type' loosely here to include class templates.
 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk