Boost logo

Boost :

Subject: Re: [boost] Interest in an 'either' library?
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2013-06-26 15:04:13

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

>> either<error, int> 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++

   result = y,

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at