Re: [boost] Monad

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

Le 25/08/15 16:36, Niall Douglas a écrit :
> On 25 Aug 2015 at 17:11, Andrey Semashev wrote:
>
>> 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.
> Monad is a far wider thing than what Haskell does with it. Many
> languages implement monads, including Rust.
How many name one of the instances of a Monad monad?
> And for reference, Rust's monad is very different from Haskell's
> monad.
How are they different?
>> 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.
> Every programming language implementing monads does it own thing. Or
> even provides more than one interpretation. I can see a future Boost
> with multiple competing monadic programming libraries.
Instances of Monads don't compete the ones with others. Each one has its 
own particularities. All of them implement two functions bind and 
unit/return_,. That's all.
>
>> 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.
> monad<T> still provides all the essential monadic programming
> operations, and it behaves mostly like a fixed function monad.
What a fixed function monad stands for.

Someone told you how you monad class would help to use a list as a Monad.
You replayed that it can juts use monad<list<U>>. Clearly you don't 
understood what the poster was requesting.
list<T> can be seen as a monad as soon as we define the convenient 
functions bind and unit. Clearly your monad class doesn't helps doing that.

Best,
Vicente