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