Re: [boost] Hana Views and References

Subject: Re: [boost] Hana Views and References
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-25 17:33:37

Lee Clagett <forum <at> leeclagett.com> writes:

> 
> On Tue, Jun 23, 2015 at 5:36 PM, Joel de Guzman <djowel <at> gmail.com> 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