Re: [boost] Monad

Subject: Re: [boost] Monad
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-08-25 14:07:57

Le 25/08/15 14:44, Niall Douglas a écrit :
> 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.
Clearly you are missing the point. You class monad could be seen as a 
model of a Monad (but don't as it doesn't defines a generic 
unit/return_/make function) as others can.
I would say that your monad class is something close to an instantiation 
of a variadic expected

     expected<T, E1, ... En>

After some request I'm thinking in extending expected<T,E> to variadic 
templates. expected<T, E1, ... En> would be something like

     variant<T, unexpected<E1>, ... unexpected<En>>

Your class would be something like

     expected<T, empty, error_code, exception_ptr>

with some specific interfaces. Am I missing something?

P.S. Note that you can already have
     expected<T, variant<empty, error_code, exception_ptr>>

The variadic version would be be more efficient and with a more friendly 
syntax.
>
>> 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.
Hmm, I prefer to don't replay here, as I don't know what you understand 
by a functional programming and I can not divine what C++ will be in the 
future.
I can not understand why do you think it shouldn't be one but I respect 
your opinion however.
>
> 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?
because naming is important.
>
> 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.
It seems that not too much people agree with your point of view. Maybe 
it is time you consider what other are saying.

>
> 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.
If you don't like expected<T>, I will suggest you to name it 
value_or_error<T>
> 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.
>
As you can see choosing the good names has its importance. With a good 
name we would be reviewing the concrete features already.

Best,
Vicente