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: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-05-25 08:27:27

On May 25, 2015 5:37:26 AM EDT, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> 
> My final design is 
> therefore ridiculously simple: a future<T> can return only these 
> options:
> 
> * A T.
> * An error_code (i.e. non-type erased error, optimally lightweight)
> * An exception_ptr (i.e. type erased exception type, allocates 
> memory, you should avoid this if you want performance)
> 
> In other words, it's a fixed function monad where the expected return 
> is T, and the unexpected return can be either exception_ptr or 
> error_code. The next gen future provides Haskell type monadic 
> operations similar to Boost.Thread + Boost.Expected, and thanks to 
> the constexpr collapse this:
> 
> future<int> test() {
>   future<int> f(5);
>   return f;
> }
> test().get();
> 
> ... turns into a "mov $5, %eax", so future<T> is now also a 
> lightweight monadic return transport capable of being directly 
> constructed.
> 
> In case you might want to know why a monadic return transport might 
> be so useful as to be a whole new design idiom for C++ 11, try 
> reading 
> https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:Stronglyconsiderusingconstexprsemanticwrappertransporttypestoreturnstatesfromfunctions.

Make the examples in that correct WRT shared_ptr. As written, the shared_ptrs will delete file handles rather than close them.

> However, future<T> doesn't seem named very "monadic", so I am 
> inclined to turn future<T> into a subclass of a type better named. 
> Options are:
> 
> * result<T>
> * maybe<T>
> 
> Or anything else you guys can think of? future<T> is then a very 
> simple subclass of the monadic implementation type, and is simply 
> some type sugar for promise<T> to use to construct a future<T>.

The idea has merit, but I have some concerns. The best practice you've linked states that there are problems with Boost.Threads' expected type, but you only mention compile times specifically. I'd like to better understand why expected cannot be improved for your case. That is, can't expected be specialized to be lighter for cases like yours?

Put another way, I'd rather one type be smart enough to handle common use cases with aplomb than to have many specialized types. I realize that doesn't solve your immediate need, but you have your own namespace so you can just create your own "expected" type until the other is improved. Then, if improvement isn't possible, you can explore another name for your expected type.

___
Rob

(Sent from my portable computation engine)