Re: [boost] Why a concrete monad class? (was Re: [next gen futures] Lightweight monad ready for inspection)

Subject: Re: [boost] Why a concrete monad class? (was Re: [next gen futures] Lightweight monad ready for inspection)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-07-01 13:22:57

Le 29/06/15 19:03, Niall Douglas a écrit :
> On 29 Jun 2015 at 17:54, Vicente J. Botet Escriba wrote:
>
>> Niall, I don't see why do you need to define a concrete monad class that
>> is used to define other monadic types. The implementation of each
>> specific monadic type has its own trade-offs.
>>
>> We can provide monadic operations for optional/expected/future/....
>>
>> Why do you need to have a concrete monad class?
>> What is the added value?
> Let me flip the question to you.
>
> Why does it matter how the monadic types are implemented? All the
> user needs to care about is that monad<T>, result<T>, option<T>,
> future<T>, future_result<T> and future_option<T> behave according to
> strict and sensible rules which make sense to program against.
If it is an implementation detail it is no worth continuing the 
discussion at the design level.
Could we then avoid to mention the monad class on these threads as it is 
an implementation detail.
So what are the public classes you would present for review?

Vicente