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

Subject: Re: [boost] [hana]Either generalization & missing variant
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-08 14:07:43

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. 

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`).
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.

2. I have focused strictly on implementing "compile-time" data structures for 
   now, since that was a sufficiently large task. So I have not taken the time 
   to think deeply about including runtime data structures like a rutime 
   variant, and the effect that would have on the library. I think it is 
   an interesting path to explore. However, I think it might be better to
   rely on an existing variant implementation and provide adapters for it
   rather than try to reinvent the wheel (plus I've heard implementing variant
   cleverly was rather challenging).

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

Regards,
Louis