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

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

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.