Re: [boost] Interest in an 'either' library?

On 25/06/13 17:18, Eric Niebler wrote:

...

either result = do( set( _x, getInt ), set( _y, getInt ), doReturn( pure( _x + _y ) ) );

If we're going to do that, lets do it generically and completely.

I've been giving serious thought to that recently. The problem with it, however, is that it requires the use of Phoenix-style lambda expressions like "_x + _y". (I can only assume you mean for _x and _y to be placeholders and not actual values. I can't think of another way to implement this.) It seems that for such core functionality, we don't want to be saddled by Phoenix's syntax and compile-times, but maybe I'm wrong.

The following Haskell syntax, transliterated to C++ do ( x, result = y, foo(result) ); is syntactic sugar for x >> y >>= [](auto result) { return foo(result); }; or even x >>= [](auto) { return y >>= [](auto result) { return foo(result); }; }; if you want to avoid specializing statements with no result. I think it is important to distinguish the support for this sugar and the monad system itself. The monad system itself is just implementing the >>= operator for the given monad type. As a matter of fact this sugar can even be implemented with macros. The syntax above is possible with minor adjustments.