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-25 10:51:17

On 25 May 2015 at 8:27, Rob Stewart wrote:

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

I would imagine destroying an open file handle would close it. 
Anyway, that really isn't important to the code examples given the 
topic, it was never mentioned what a handle_type is, I had an 
afio::async_io_handle in mind but it doesn't matter.

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

I am one of few here who has seen Expected deployed onto a large code 
base. The other guy is Lee, who has even more experience than I do. 
Ours was not a positive experience in a real world large code base 
use scenario.

Expected is a great library. Lovely piece of work. However, it is 
also enormous. For a simple monadic return transport with traditional 
unexpected type exception_ptr, it is enormously overkill. It does 
category theory, huge quantities of constexpr machinery, and a fair 
chunk of what a variant implementation would need. This is why it is 
so slow on compile times.

When we were using expected, 98% of the time we didn't need any of 
that. We just wanted a simple Either-Or object which imposed optimal 
compile and runtime overhead. We just wanted to return some expected 
type T, or some error, and the monadic operations to work as 
described without any extra fluff like comparison operations, 
hashing, container semantics, automatic conversion, variant semantics 
etc.

Also, in terms of it now being 2015, we know WG21 are working on an 
official variant type - it was the talk of C++ Now. Such a variant is 
an obvious base class for any expected implementation rather than 
reinventing the wheel separately.

Similarly, the future-ishy parts of expected would make more sense to 
come from a base future-ishy type which is then composed with a 
variant type to make an expected type which does all the singing and 
dancing anyone could desire. That means rewriting expected from 
scratch sometime later on.

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

Mine isn't an expected implementation. It doesn't even do optional 
semantics, or even value semantics. It simply provides the simple 
future API on a fixed variant wrapper type - three quarters of a 
std::future - nothing more.

If you have ever done a lot of make_ready_future() in your code as a 
quick and dirty Maybe implementation (I know I have), this use is 
exactly what I am trying to formalise into an enormously more 
efficient implementation.

Niall

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