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.