Re: [boost] [next gen future-promise] What to call the monadic return type?

Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-05-27 01:46:28

Le 27/05/15 01:36, Niall Douglas a écrit :
> On 26 May 2015 at 19:56, Vicente J. Botet Escriba wrote:
>
>>> Names suggested so far are maybe, result, holder, value.
>> Neither result, holder nor value conveys the fact that the value can not
>> be there. maybe<T> has already the connotation T or nothing as optional.
>> There is no place for error_code and exception_ptr. If the type is not
>> related to thread synchronization, here they are some alternative names:
>> probably_value<T>, probable<T>?
> probable<T> vs result<T> vs maybe<T>. Hmm, I'll have to think about
> it.
>
>>> result<int> v(5);
>>> assert(v.get()==5);
>>> v.set_value(6);
>>> assert(v.get()==6);
>>> v.set_exception(foo());
>>> v.get(); // throws foo
>>> v.set_error(error_code);
>>> v.get(); // throws system_error(error_code)
>> This is quite close to expected, isn't it?
> I lean on expected's design yes. I like the expected design. No point
> inventing a new API after all, we know yours works.
>
>>> The compiler treats a default initialised monad identically to a void
>>> return i.e. zero overhead.
>> Ah, then the to be named type has the additional ready state. This is
>> closer to a valid future with the addition of the promise (setting)
>> interface.
> Exactly right. No surprises.
>
>> I have no problem. There are not proper and dirty monads. Purist will
>> give you the good name. I see several nested monads.
>> IIUC, the type doesn't has the invalid state, isn't it?
> It has valid() on the future<T>. But not on the monad. So I suppose
> not.
Then you to be named type is between expected and future.
if it can be used asynchronously it could be seen as a valid_future<T>. 
Then a future coul dbe seen as a specialization of 
optional<valid_future<T>>.
Otherwise, if it is synchronous, it could be seen as an specialization 
of optional<expected<T>>.

Does your "to be named" type provide wait(), then() , ....?
>
>>> expected integration is very far away for me. I'm even a fair
>>> distance from continuations, because getting a std::vector to
>>> constexpr collapse is tricky, and you need a
>>> std::vector<std::function> to hold the continuations.
>> Why do you need to store store a vector of continuations. You have just
>> one. What am I missing?
> It makes my implementation a lot easier if I can add an unknown
> number of continuations (non-consuming, therefore they are really C
> type callbacks) to some future. Remember I am optionally supporting
> Boost.Fiber later on, and I need an extensible and generic way of
> firing off coroutines on future signal with minimal #ifdef code
> branches all over the place.
>
> Under the Concurrency TS you'd implement this by creating a callable
> struct which contains the vector of more continuations, so as an
> example:
>
> struct many_continuations
> {
>    std::vector<std::function<void(const std::future &)>> nonconsuming;
>    std::function<void(std::future)> consuming;
>    void operator()(std::future v)
>    {
>      for(auto &c : nonconsuming)
>        c(v);
>    }
>    consuming(v);
> };
>
> ... and now do future.then(many_continuations());
>
> I'm simply building that same functionality straight into my future
> instead of having external code bolt it on.
This is a functionality that shared_future<T> accepts already. Note that 
shared here is related to the underlying T value.
As you said, don't pay for what you don't use. The many_continualions 
functor is only one way to achieve that. If you (the user) are looking 
for performances you can have a more intrusive solution.
Does your "to be named" type provide this kind of 
consuming/not-consuming  continuations?
It is difficult to nane something we don't know which interface and 
semantics it has.
>
>>> My main goal is
>>> getting AFIO past peer review for now.
>>>
>> As others I'm waiting for a written proposal. But I think this is not on
>> your plans.
> Nope. My priority is AFIO. I have about two months to deliver it.
> We'll go from there after.
>
If we are discussing here of internal implementation details of AFIO, I 
would suggest you spent this time to improve the interface and the 
documentation and documenting the performances. You will have all the 
time to improve the implementation and its performances before going to 
a release.

If we are discussing here of another possible boost classes (even if 
only part of AFIO), then it is different.

In other words, would the "to be named" type appear on the AFIO 
interface? Is for this reason that you need to name it? or it is really 
an implementation detail. This merits clarification.

Best,
Vicente