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

Subject: Re: [boost] Interest in an 'either' library?
From: David Sankel (camior_at_[hidden])
Date: 2013-06-24 23:40:08

On Mon, Jun 24, 2013 at 5:20 AM, Pierre T. <ptalbot_at_[hidden]> wrote:

> For example, compare the following definition,
>>
>> optional< either< isbn_10, isbn_13 > > parse_isbn_string( std::string );
>>
>> to the equivalent using the 'expected' wording,
>>
>> optional< expected< isbn_10, isbn_13 > > parse_isbn_string( std::string );
>>
>>
> I think there is some misunderstanding and confusion between
> Expected/Optional/Either. Indeed, I'm quite sure that Expected and Either
> are completely different. Even if Expected seems to be a subset of Either,
> because you can choose to return a (value,
> exception/error) couple in Either, the behavior will be different. IMHO,
> Expected is more useful because it adds a lot of semantics for this
> particular use-case.
>

I think the misunderstanding is between the precise meanings of syntax and
semantics. The expected class and the either class are *semantically*
equivalent. That is, if we map them to their precise mathematical meanings,
they are the same. [[either<A,B>]] = A + B = [[expected<A,B>]] (I'm using
ADT syntax here for the mathematical domain (see:
http://cpp-next.com/archive/2010/07/algebraic-data-types/)).

They are *syntactically* different in that different names were chosen.

> I'd say that if Expected is the brother of Optional, Either is the child
> of Variant (because it's a subset without adding specific semantic).
>
>
I have no idea what you mean by 'brother' and 'child'.

To correct the example above, it should be:
>
>
> optional< either< isbn_10, isbn_13 > > parse_isbn_string( std::string );
>
> OR
>
> expected< either< isbn_10, isbn_13 > > parse_isbn_string( std::string );
>
> Depending on the design of parse_isbn_string – if it says or not why the
> parsing failed.
>

Okay, I think you've made it clear that you'd like to limit the application
of expected to a particular use case that isn't implied by the semantics,
but only by the author's intention.

This is a bad design strategy IMO. A good reusable library will be
documented by its semantics primarily and provide use-cases to give the
user hints of where it will be useful (but never limit the user by the
author's necessarily limited foresight)

> I think Either could be useful in case it's massively used to avoid the
> syntactic overhead of Variant.
>
> Finally, the first argument of this Either library was the error/value
> couple facilities, but now we know that Expected is quite better, does
> Either is just syntactic sugar ? Or do you have other relevant use cases ?
>

I don't think it has been demonstrated that "expected is quite better".
There are plenty of use cases for either because it is such a fundamental
type. Here are just a few handy generic functions (using Haskell type
syntax for conciseness):

either :: (a -> c) -> (b -> c) -> Either a b -> c
partitionEithers :: [Either a b] -> ([a], [b])
mapEither :: (a -> Either b c) -> IntMap a -> (IntMap b, IntMap c)
lefts :: [Either a b] -> [a]
rights :: [Either a b] -> [b]
liftRight :: a -> Either a b
liftLeft :: a -> Either b a

David