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

Subject: Re: [boost] Interest in an 'either' library?
From: Eric Niebler (eniebler_at_[hidden])
Date: 2013-06-25 11:18:17

On 6/24/2013 8:55 PM, David Sankel wrote:
> On Mon, Jun 24, 2013 at 1:19 PM, Eric Niebler <eniebler_at_[hidden]> wrote:
> 
>> On 13-06-24 11:53 AM, Pierre Talbot wrote:
>>>>
>>>> This misses what is, IMO, the most important use case of Haskell's
>>>> Either monad: automatic error propagation. This would be more useful if
>>>> there were a way to call a function such that if any of the function's
>>>> arguments were an Either-in-error, the function would immediately return
>>>> the error.
>>>>
>>>> I implemented something like this. Check out substitution_failure and
>>>> try_call starting here:
>>>>
>>>>
>> https://github.com/ericniebler/proto-0x/blob/master/boost/proto/v5/utility.hpp#L742
>>>
>>> In the Expected proposal, there are some methods related to this idea.
>>
>>
> <snip various do-syntax derivatives>
> 
> If we really care about adding a do syntax EDSL, why not make it general
> purpose like Haskell's version so that it can work with any monad and
> compose better with other things?
> 
> 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.

Anyhow, yes, I think something like this should exists. Phoenix could
provide one implementation. FWIW, I just pushed another monad-in-c++ up
to my github last night (the first link is the state monad, the second
is an example that uses it):
https://github.com/ericniebler/fpxx/blob/master/include/fpxx/monad/state.hpp
https://github.com/ericniebler/fpxx/blob/master/example/state.cpp

But I don't think this obviates the need for the try_call that I was
suggesting. It is extremely light-weight and let's people write ordinary
C++ instead of Phoenix. And I think it would be easier to teach to C++
programmers.

>>> I honestly think that if Either goes into Boost, we shouldn't consider
>>> it as a value or error structure at all. Expected (will) do the job.
>>
>> Seems a bit excessive to me to have both. If we get Expected, then
>> Either is unnecessary -- it's just one template alias away from variant.
>> I don't consider the syntactic niceties of "left" and "right" to be
>> compelling, and if folks want it, we can provide left and right free
>> functions for 2-arg variants. But IMO automatic error propagation is the
>> *only* thing that can make this proposal compelling.
> 
> I personally find myself using std::pair frequently even though it is also
> just one template alias away from std::tuple. I still think there's a case
> for exposing these commonly-useful simple building blocks. Incidentally,
> the std::pair monad is also interesting.

I use it too. But I tend to believe that if C++ got std::tuple first,
std::pair really would just be a template alias for a 2-tuple. That's
obviously just my opinion, though.

-- 
Eric Niebler
Boost.org
http://www.boost.org