From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-10 20:34:29
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