On 6/26/15 5:24 AM, Louis Dionne wrote:
Joel de Guzman
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/