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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-26 19:36:26

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.

> > 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.

> > 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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/