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

On 06/08/2015 01:07 PM, Louis Dionne wrote:

Larry Evans 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) right(b) ~=~ variant(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, where either_t 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.

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::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/... 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/...

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