Eric Niebler wrote:
Joel de Guzman wrote:
Eric Niebler wrote:
- What is your evaluation of the design?
Very nice. Joel and Dan have put a lot of thought into the design of Fusion. Lazy heterogeneous sequences are very powerful. As Joel and I have discussed extensively in recent weeks, support for segmented data structures would make traversal of some sorts of sequences much more efficient. Joel seems interested and committed to making these changes, and I'm happy to help.
I think the segmentation idea is very good. I love the direction that this is leading to. Thank you very much for spear-heading the effort.
My pleasure. FYI - I now have a general implementation of fusion::segmented_iterator<>, so we can proceed with our simplified segmentation interface.
Awesome!
Like Dave, I'd like to see some more thought put into the extensibility mechanism. Defining new Fusion iterators is a bit painful, and something like a Fusion iterator adaptor library might be very useful. That might be possible if the metafunctions were all part of the same struct. I'd be satisfied with an analysis that breaks down the pros and cons of such an approach.
As I mentioned in my reply to Eric Friedman, the extensibility mechanism is no more difficult than extending MPL. It just so happens that the extension section gave a not so trivial example (that of a random access and associative sequence). Anyway, I do agree that a better extension mechanism, if one can be found, would be a definite boon to using Fusion.
I am imagining an interface similar to Boost.Iterator's iterator_facade<>. That would make it possible to easily adapt the implementation from another fusion iterator. The Fusion filter_view and transform_view can be build on top just as Boost.Iterator's filter_iterator and transform_iterator are built on top of iterator_facade<>.
Same thinking here. I think I just concocted a solution before I went to bed last night.
Some miscelaneous questions:
- Why is there a traits::tag_of<> for extracting the sequence tag, but no corresponding metafunction for extracting the iterator's tag?
traits::tag_of<> should be usable for iterators too. The docs should make that clear.
Nope. There's code like this, from fusion/iterator/next.hpp:
namespace result_of { template <typename Iterator> struct next { typedef typename extension::next_impl<typename Iterator::ftag>:: template apply<Iterator>::type type; }; }
That is clearly wrong. Noted.
You're accessing the nested Iterator::ftag directly. You should be using the tag_of<> metafunction here, otherwise specializing it will have no effect.
Right.
- Why do I have to declare both my sequence's category *and* my iterator's category? Won't there always be an obvious relation between them? Iterators do not have the exact same categories as sequences. For example, iterators do not have the associative category.
But you have an is_associative<> metafunction. Why do you need an associative sequence category? IMO, sequences shouldn't have catogories. Iterators should have categories, and sequences have iterators. Extra information, like whether the sequence is associative, should be provided by specializing external traits, like is_associative. Otherwise, you have duplication. (Eg., of course a forward sequence has forward iterators!)
Hmmm... You have a point.
Thanks! What directory structure do you have in mind?
Less nesting. IMO there is no reason for there to be iteration/, query/, and transformation/ sub-directories under algorithm. Just put all the algorithms in algorithm/. IMO, all the subdirectories under sequence/ are unnecessary, too. I've had to grep through the tree structure to find the header I'm looking for. That's crazy.
If you don't want to flatten the tree structure (seems we spend a lot of time talking about flattening trees ;-), I like the approach taken by Boost.PP. There is a tree structure, but also top-level headers that simply #include the correct header from the sub-directory. That way, if I want to use boost::fusion::begin() I can just #include <boost/fusion/begin.hpp> without needing to know that it actually lives at <boost/fusion/sequence/intrinsic/begin.hpp>.
Yes, that's part of the plan, in fact. There will be a header directory where all the forwarding headers can be found. Cheers! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net