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

On 6/24/2013 8:55 PM, David Sankel wrote:

On Mon, Jun 24, 2013 at 1:19 PM, Eric Niebler 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.h...

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