Re: [boost] [hana]Either generalization & missing variant

Subject: Re: [boost] [hana]Either generalization & missing variant
From: Larry Evans (cppljevans_at_[hidden])
Date: 2015-06-08 15:00:07

On 06/08/2015 01:07 PM, Louis Dionne wrote:
> Larry Evans <cppljevans <at> suddenlink.net> writes:
> 
>>
>> The page:
>>
>>   http://ldionne.com/hana/structboost_1_1hana_1_1Either.html
>>
>> contains:
>>
>> [...]
>>
>> which makes anyone familiar with boost::variant to think
>> that hana's Either is simply a binary boost::variant, and
>>
>>   left(a)   ~=~  variant<A,B>(a)
>>   right(b)  ~=~  variant<A,B>(b)
>>
>> where ~=~ means some sort of similarity.
>>
>> [...]
>>
>> But why should Either be limited just to _left and _right
>> wrappers.  Why not provide wrapper's tagged by some
>> enumerable?  For example, something like this:
>>
>> [...]
> 
> Funny you brought this up; I just decided this morning to remove Either from 
> the official documentation to give me some more time to think about it, and
> then I read your email.
> 
> Either is effectively a binary variant, which could be generalized. However,
> since it is meant to be a static variant, i.e. one whose internal type is 
> known at compile-time, it is in some sense equivalent to just an object of 
> that type. It is also implemented precisely as such.
> 
> There is a different mathematical way to view Hana's Either which makes it
> an actual variant over something, and this is the reason I initially added
> Either; mainly for completeness and for trying to validate the correctness
> of this mathematical viewpoint. 

What puzzled me was initially, was that left(a) and right(b) produced
_left<A> and _right<B> and there was no indication that the
result was of type either_t<A,B>, where either_t<A,B> is
a variant like in boost::variant.  Hence, I don't think
the way hana implements Either, it can truly be a discriminated union
because _left<A> has no information about what the other possible
alternative values are in either_t<A,B>.

> 
> However, I have frankly not found any actual use case for Either, so I 
> ignored it for a while and now I decided to set it aside until I have a 
> better idea of how/if it can be useful.
> 
> 
>> [...]
>>
>> OTOH, Either, or the generalization described above, can't
>> be used where a true variant is needed, for example, in
>> spirit's attributes for the alternative parser.  And this
>> brings up another question.  Although hana has a tuple, it
>> doesn't have a variant.  Is there any reason for excluding
>> variant from hana?
> 
> I will assume you mean an actual runtime variant (like `boost::variant`).

Yes.

> I'd say there are two reasons for this omission. 
> 
> 1. In the mathematical construction upon which Hana stands, sum types are 
>    exactly Either as currently implemented. An actual runtime variant can't
>    be implemented (while staying in that mathematical universe). However, 
>    runtime variants might be a very useful addition to Hana, allowing one 
>    to have a compile-time computation depending on a runtime value to return
>    a runtime variant instead of failing because the result can't be determined
>    at compile-time, like it currently does. This brings us to the second point.

That's what I would have thought.  IOW, the type returned by get depends
on the *runtime* value of the discriminant (the value returned
by variant<T1,...,Tn>::which().  However, I think there have been
some constexpr get's for variant structures, at least as for as I can
tell from reading:

https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/detail/storage.hpp#L82

and:

http://article.gmane.org/gmane.comp.lib.boost.devel/259044

which says:

> yet.  The egg code mentioned by gonzalobg88 <at> gmail.com:
>
>
https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/detail/storage.hpp#L88
>
> had several constexpr( or at least EGGS_CXX11_CONSTEXPR) functions.
> Are one of those requiring a recursive union for implementation?

Yes, pretty much all of them require a recursive union for constexpr
support. The details can be found here
http://talesofcpp.fusionfenix.com/post-20/eggs.variant---part-ii-the-constexpr-experience

and here https://akrzemi1.wordpress.com/2012/12/13/constexpr-unions/

[snip]

> So the bottom line is: Hana does not officially provide a sum type 
> (variant/Either) for now, and it is not useful as far as my experience 
> shows. 

spirit uses variants as the attributes of alternative parsers:

https://github.com/djowel/spirit_x3/blob/master/example/x3/calc5.cpp#L43

Is there something spirit could be using instead?

> However, I will take some more time to think about it and come 
> up with a good reason to exclude it or a better/generalized interface
> for it, but after the review. See it as a potential feature of a future
> version of the library.
> 

Thanks Louis.

-regards,
Larry