Lee Clagett
On Tue, Jun 23, 2015 at 5:36 PM, Joel de Guzman
wrote: 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?
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. Faster runtime performance is also questionable, when lightweight views and reference members come into play.
Hana has an adaption layer for boost fusion, that has no documentation. This adaption code could use some work - it should be able to use fusion traits for more generic adaption, making all fusion sequences (including views and adapted structs) compatible with Hana. `concat_impl` could return a sequence-view (currently it moves/copies elements into a new sequence), `remove_at_impl` (not currently implemented) could use `fusion::filter_if<>` to avoid element moving/copying, etc. I think this could be useful in a number of scenarios similar to the transform in place discussion from another thread.
Indeed; the adaptation layer for Fusion could be improved and it might be possible to support views in this way. However, I'd have to make sure that views can be made to fit the concepts provided by Hana (which might be the case if you consider views to be equivalent to normal sequences, except everything is computed lazily). For example, in practice it is totally possible to have `concat` return a view, but I'd like to make sure it makes sense mathematically.
I'm not sure that Hana should provide this view functionality directly, but it seems like it should list these differences in the documentation. In fact, should Hana leverage fusion::tuple instead of its own tuple implemention (Fusion is undergoing a C++11 upgrade so compilation time difference should be negligible)?
Some algorithms have to be tightly coupled to the tuple's implementation to ensure good compile-time performance, so I don't think this would be feasible. I'd also like to stay in control of tuple, since it is literally THE most core structure of the library, rather than rely on another library for that.
Something to consider since it looks like multiple tuple implementations are going to be maintained in boost.
Lee
Regards, Louis