Re: [boost] Hana Views and References

Subject: Re: [boost] Hana Views and References
From: Joel de Guzman (djowel_at_[hidden])
Date: 2015-06-25 20:41:20

On 6/26/15 5:24 AM, Louis Dionne wrote:
> Joel de Guzman <djowel <at> gmail.com> writes:
>
>>
>> Hello Louis,
>>
>> Mario Lang, a Spirit developer, played around with Hana and
>> investigated on it's suitability for Spirit. His conclusion
>> is that "Hana is really quite nice!". Then, he adds that:
>> "However, Hana lacks a way to retrieve the members of a
>> struct as references currently, which will pretty much kill
>> a Hana based Spirit effort."
>
> Indeed, this will change once this issue [1] is resolved.
>
>
>> So the question is: will Hana support references without
>> resorting to using reference wrappers? I do appreciate
>> the FP nature of Hana, but please be reminded that we're
>> in C++.
>>
>> I also recall some discussion that Hana also does not support
>> Fusion-like lightweight views. Is there a plan to support them?
>
> If we find use cases where views would really be helpful, then that's
> a feature that could be added. I'm open to the possibility, but right
> now there are (1) more urgent things to improve (2) no clear use case
> that require views. However, I haven't given a lot of thought to it,
> so I might be missing some obvious use cases.
>
> Also note that views like in Fusion would actually take Hana further
> away from C++, where we are used to eager evaluation. Adding laziness
> to Hana would give it an even more FP taste. This is just an observation.

So Fusion is more FP than Hana in that regard. Views are not new in
C++. There are examples of it. Eric's Ranges come to mind.

>> I haven't fully investigated yet what else Hana does not support
>> that Fusion does, but at least these two important aspects of
>> fusion come to mind. At the very least, I don't think Hana should
>> advertize itself as a superset of Boost.Fusion.
>
> The first aspect is a bug, and the second aspect is more like a different
> design choice, since Fusion supports only "lightweight views", and no
> eager algorithms. What is meant is that all of Fusions's algorithms are
> implemented in Hana (and more), which is true. I don't think saying Hana
> is a superset of Fusion is detrimental to Fusion, but I could reword that
> sentence of the tutorial if you feel like it is detrimental.
>
>
>> Faster runtime performance is also questionable, when lightweight
>> views and reference members come into play.
>
> Hana claims to be at least as good as Fusion runtime-wise, which is
> backed by the benchmarks presented in the tutorial. It is possible
> that idiomatic usage of Hana leads to worse runtime performance than
> with Fusion, in which case the library and its idioms will have to be
> adjusted. Like I said a few times, Hana is a new library with a new
> paradigm, and I think we're only starting to discover how it can be
> used (and used efficiently).

Your tests focused on a mere subset of Fusion which is the least
optimized: fusion::vector. Your tests do not cover other areas
such as views, and other containers. I can imagine a case, when say
you push_back or insert where views should shine. It's the difference
between copy by value and pass by reference. Try doing that with large
tuple elements (those without resources and are not efficiently
moved). Actually, have you tried reverse with large tuples like
bitmaps and stuff?

Hmmmm, how did you test reverse in Fusion BTW? Fusion reverse should
return a view with ZERO(!) copy. Did you create another vector from the
reverse_view? I guess so, since your test subject is Fusion vector.
In that case, you are not doing it right! You don't copy to another
vector. You should use the results as-is. Lazily.

For that matter, the same is true with transform! Fusion returns
transform_view. You should get zero overhead with those because
they are lazy. If you are copying back to a fusion vector, then
you are not doing it right. Have you tried accessing, say only
the Nth element instead of (presumably) copying back to a vector
before accessing the Nth element? or how about transforming only
a range within the container?

It seems you are doing your tests unfairly using eager evaluation
(Hana) instead of lazy evaluation (Fusion).

Regards,
-- 
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/