libs/iterator/doc/iterator_facade.html typo?
libs/iterator/doc/iterator_facade.html#tutorial-example In the section "Template Arguments for iterator_facade" is the subsection "CategoryOrTraversal". I suspect that should be "CategoryOfTraversal" (s/Or/Of/). The iterator_adapter docs spell it "CategoryOrTraversal" too. Regards, Angus
Angus Leeming <angus.leeming@btopenworld.com> writes:
libs/iterator/doc/iterator_facade.html#tutorial-example
In the section "Template Arguments for iterator_facade" is the subsection "CategoryOrTraversal". I suspect that should be "CategoryOfTraversal" (s/Or/Of/).
The iterator_adapter docs spell it "CategoryOrTraversal" too.
No, the spelling is as intended. It's either an iterator category tag (such as std::random_access_iterator_tag) or an iterator traversal tag (such as boost::random_access_traversal_tag). -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
In the section "Template Arguments for iterator_facade" is the subsection "CategoryOrTraversal". I suspect that should be "CategoryOfTraversal" (s/Or/Of/).
The iterator_adapter docs spell it "CategoryOrTraversal" too.
No, the spelling is as intended.
It's either an iterator category tag (such as std::random_access_iterator_tag) or an iterator traversal tag (such as boost::random_access_traversal_tag).
Thanks for the explanation. Would it not be worthwhile putting something like this in the documentation? Perhaps in iterator_facade.html#tutorial-example where the CategoryOrTraversal template parameter is explained and where the explanation mentions 'iterator tranversal concepts' only. Indeed clicking on the link of that name takes me to a point where the tables again mention only traversal. Back to reading the docs. Kind regards, Angus
Angus Leeming <angus.leeming@btopenworld.com> writes:
David Abrahams wrote:
In the section "Template Arguments for iterator_facade" is the subsection "CategoryOrTraversal". I suspect that should be "CategoryOfTraversal" (s/Or/Of/).
The iterator_adapter docs spell it "CategoryOrTraversal" too.
No, the spelling is as intended.
It's either an iterator category tag (such as std::random_access_iterator_tag) or an iterator traversal tag (such as boost::random_access_traversal_tag).
Thanks for the explanation.
Would it not be worthwhile putting something like this in the documentation? Perhaps in iterator_facade.html#tutorial-example where the CategoryOrTraversal template parameter is explained and where the explanation mentions 'iterator tranversal concepts' only. Indeed clicking on the link of that name takes me to a point where the tables again mention only traversal.
Huh? CategoryOrTraversal Now we have to determine which iterator traversal concept our node_iterator is going to model. Singly-linked lists only have forward links, so our iterator can't can't be a bidirectional traversal iterator. Our iterator should be able to make multiple passes over the same linked list (unlike, say, an istream_iterator which consumes the stream it traverses), so it must be a forward traversal iterator. Therefore, we'll pass boost::forward_traversal_tag in this position [1]. [1] iterator_facade also supports old-style category tags, so we could have passed std::forward_iterator_tag here; either way, the resulting iterator's iterator_category will end up being std::forward_iterator_tag. What am I missing? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Huh?
CategoryOrTraversal
Now we have to determine which iterator traversal concept our node_iterator is going to model. Singly-linked lists only have forward links, so our iterator can't can't be a bidirectional traversal iterator. Our iterator should be able to make multiple passes over the same linked list (unlike, say, an istream_iterator which consumes the stream it traverses), so it must be a forward traversal iterator. Therefore, we'll pass boost::forward_traversal_tag in this position [1].
[1] iterator_facade also supports old-style category tags, so we could have passed std::forward_iterator_tag here; either way, the resulting iterator's iterator_category will end up being std::forward_iterator_tag.
What am I missing?
I am obviously blind and brain dead. Apologies for the noise. Angus
David Abrahams wrote:
Angus Leeming <angus.leeming@btopenworld.com> writes:
David Abrahams wrote:
In the section "Template Arguments for iterator_facade" is the subsection "CategoryOrTraversal". I suspect that should be "CategoryOfTraversal" (s/Or/Of/).
The iterator_adapter docs spell it "CategoryOrTraversal" too.
No, the spelling is as intended.
The naming of the implementation, and the (informal, so far?) proposal by you, Siek and Witt (sp?), is a bit misleading. A few comments/suggestions: 1. A group of concepts should be called either "group" or "category" (I think you stick to the former most, of not all, of the time) consistently in both proposal and implementation. 2. Why is one concept group (i.e., one part of the dichotomy) called "category" and the other "traversal." Potential confusion ahead... I propose "access" and "traversal," since I see no more of a "categorically" intrinsic property in one group than the other, i.e., labeling the access dimension as categorical is a bit unfair to the poor traversal dimension ;-) Furthermore, connected to (1), category is often used to denote a group of concepts, so I understand Angus' confusion. 3. In the traversal group/category of concepts, they should either *all* include the lexeme "traversal" or *none*. In fact, I propose to completely skip the "traversal" in the concept names. The only potential conceptual hurdle is the "access" in "random_access" (or RandomAccessIterator) that can be confused with the access-related group of concepts... 4. The access group of iterator concepts: what is so "iterative" about them? I.e., are they not general proxy concepts, with potential applications in smart pointers and other proxy situations? Comment (4) above is a bit whimsical, admittedly, and I do understand the benefit of sticking to Iterator in the discussions, to easier combine with existing notions and concepts in STL. /David
"David Bergman" <davidb@home.se> writes:
David Abrahams wrote:
Angus Leeming <angus.leeming@btopenworld.com> writes:
David Abrahams wrote:
In the section "Template Arguments for iterator_facade" is the subsection "CategoryOrTraversal". I suspect that should be "CategoryOfTraversal" (s/Or/Of/).
The iterator_adapter docs spell it "CategoryOrTraversal" too.
No, the spelling is as intended.
The naming of the implementation, and the (informal, so far?) proposal by you, Siek and Witt (sp?), is a bit misleading.
Well, it seems as though you were misled somewhere along the way.
A few comments/suggestions:
1. A group of concepts should be called either "group" or "category" (I think you stick to the former most, of not all, of the time) consistently in both proposal and implementation.
I have no idea what you're referring to. Maybe you should specifically point to text you think should be changed, and why.
2. Why is one concept group (i.e., one part of the dichotomy) called "category"
Because that's what the existing standard calls it.
and the other "traversal."
Because that's what it describes.
Potential confusion ahead... I propose "access" and "traversal,"
Existing category tags do not describe just access. They describe a combination of access and traversal, as you can see by reading http://www.boost.org/libs/iterator/doc/new-iter-concepts.html
since I see no more of a "categorically" intrinsic property in one group than the other, i.e., labeling the access dimension as categorical is a bit unfair to the poor traversal dimension ;-)
It would be, but we're not doing that.
Furthermore, connected to (1), category is often used to denote a group of concepts, so I understand Angus' confusion.
I don't know what you're talking about again.
3. In the traversal group/category of concepts, they should either *all* include the lexeme "traversal" or *none*.
Probably a good idea. We made that change to the tags, but not to the concept names.
In fact, I propose to completely skip the "traversal" in the concept names. The only potential conceptual hurdle is the "access" in "random_access" (or RandomAccessIterator) that can be confused with the access-related group of concepts...
Bad idea, IMO. incrementable_tag, for example, shouldn't be reserved by an iterators library; it could apply to lots of things.
4. The access group of iterator concepts: what is so "iterative" about them? I.e., are they not general proxy concepts, with potential applications in smart pointers and other proxy situations?
...and your point is...? They were designed so that they could be used independently from traversal.
Comment (4) above is a bit whimsical, admittedly, and I do understand the benefit of sticking to Iterator in the discussions, to easier combine with existing notions and concepts in STL.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"David Bergman" <davidb@home.se> writes:
David Abrahams wrote:
Angus Leeming <angus.leeming@btopenworld.com> writes:
David Abrahams wrote:
In the section "Template Arguments for iterator_facade" is the subsection "CategoryOrTraversal". I suspect that should be "CategoryOfTraversal" (s/Or/Of/).
The iterator_adapter docs spell it "CategoryOrTraversal" too.
No, the spelling is as intended.
The naming of the implementation, and the (informal, so far?) proposal by you, Siek and Witt (sp?), is a bit misleading.
Well, it seems as though you were misled somewhere along the way.
Ok, let us see.
A few comments/suggestions:
1. A group of concepts should be called either "group" or "category" (I think you stick to the former most, of not all, of the time) consistently in both proposal and implementation.
I have no idea what you're referring to. Maybe you should specifically point to text you think should be changed, and why.
I think you have an idea of what I am talking: the proper name to use for the concept groups. You want to stick to "group" because the Standard uses that name. Fine, makes sense. I have seen "category" being used for that notion.
2. Why is one concept group (i.e., one part of the dichotomy) called "category"
Because that's what the existing standard calls it.
The existing standard does not even split the Iterator group into two dimensions, so how can they call that not-yet-invented dimension anything? They use "category tags" for tags to groups, and subgroups, of concepts. I.e., their use has nothing to do with the "access" dimension. Additionally, does not "category tags" for tagging groups of concepts somehow imply that the word "category" for concept groups is not all that far far-fetched.
and the other "traversal."
Because that's what it describes.
Fine.
Potential confusion ahead... I propose "access" and "traversal,"
Existing category tags do not describe just access. They describe a combination of access and traversal, as you can see by reading http://www.boost.org/libs/iterator/doc/new-iter-concepts.html
Category tags is one thing, the "access" dimension another. This is where the possible confusion might arise: a. groups of concepts - called "groups" b. the tag used to label a group, or subgroup, of concepts - called "category tag" c. the access group of concepts pertaining to iterators - called "category"?
since I see no more of a "categorically" intrinsic property in one group than the other, i.e., labeling the access dimension as categorical is a bit unfair to the poor traversal dimension ;-)
It would be, but we're not doing that.
So, what are you calling that other, orthogonal group, if not "category"?
Furthermore, connected to (1), category is often used to denote a group of concepts, so I understand Angus' confusion.
I don't know what you're talking about again.
You do not know that the word "category" is often used to denote a group of concepts in generic programming? As in "category tags."
3. In the traversal group/category of concepts, they should either *all* include the lexeme "traversal" or *none*.
Probably a good idea. We made that change to the tags, but not to the concept names.
Ok.
In fact, I propose to completely skip the "traversal" in the concept names. The only potential conceptual hurdle is the "access" in "random_access" (or RandomAccessIterator) that can be confused with the access-related group of concepts...
Bad idea, IMO. incrementable_tag, for example, shouldn't be reserved by an iterators library; it could apply to lots of things.
I agree with that cross-group applicability of the tag, but what has that insight to do with skipping "traversal" in the concept names?
4. The access group of iterator concepts: what is so "iterative" about them? I.e., are they not general proxy concepts, with potential applications in smart pointers and other proxy situations?
...and your point is...?
Exactly the point you made in your last comment, namely, that "it could apply to lots of things."
They were designed so that they could be used independently from traversal.
That was the point I was making... /David
"David Bergman" <davidb@home.se> writes:
The naming of the implementation, and the (informal, so far?) proposal by you, Siek and Witt (sp?), is a bit misleading.
BTW, the proposal is not informal. It was accepted into the TR.
Well, it seems as though you were misled somewhere along the way.
Ok, let us see.
A few comments/suggestions:
1. A group of concepts should be called either "group" or "category" (I think you stick to the former most, of not all, of the time) consistently in both proposal and implementation.
I have no idea what you're referring to. Maybe you should specifically point to text you think should be changed, and why.
I think you have an idea of what I am talking: the proper name to use for the concept groups.
No, I really don't. What is a "concept group"?
You want to stick to "group" because the Standard uses that name.
I do? Where does the Standard use that name?
Fine, makes sense. I have seen "category" being used for that notion.
I'm still lost. Why don't you just take my suggestion instead of insisting that I already know what you're talking about? Quote some text from the paper, say "I think it should say ________", and then say why you think so. It's not so hard.
2. Why is one concept group (i.e., one part of the dichotomy) called "category"
Because that's what the existing standard calls it.
The existing standard does not even split the Iterator group into two dimensions, so how can they call that not-yet-invented dimension anything?
The standard defines "iterator categories".
They use "category tags" for tags to groups, and subgroups, of concepts. I.e., their use has nothing to do with the "access" dimension.
It incorporates the "access" dimension.
Additionally, does not "category tags" for tagging groups of concepts somehow imply that the word "category" for concept groups is not all that far far-fetched.
I still don't know what "concept group" means.
and the other "traversal."
Because that's what it describes.
Fine.
Potential confusion ahead... I propose "access" and "traversal,"
Those are already the terms we use.
Existing category tags do not describe just access. They describe a combination of access and traversal, as you can see by reading http://www.boost.org/libs/iterator/doc/new-iter-concepts.html
Category tags is one thing, the "access" dimension another. This is where the possible confusion might arise:
a. groups of concepts - called "groups"
b. the tag used to label a group, or subgroup, of concepts - called "category tag"
The term "category tag" refers to tags such as std::random_access_iterator_tag corresponding to old-style iterator categories, such as "random access iterator". The term "traversal tag" refers to tags such as boost::random_access_traversal_tag corresponding to iterator traversal concepts, such as "random access traversal iterator".
c. the access group of concepts pertaining to iterators - called "category"?
No, I'm telling you that we're not using the word "category" to describe access concepts. "Category" was established by the existing standard, and it mashes together traversal and access.
since I see no more of a "categorically" intrinsic property in one group than the other, i.e., labeling the access dimension as categorical is a bit unfair to the poor traversal dimension ;-)
It would be, but we're not doing that.
So, what are you calling that other, orthogonal group, if not "category"?
Access
Furthermore, connected to (1), category is often used to denote a group of concepts, so I understand Angus' confusion.
I don't know what you're talking about again.
You do not know that the word "category" is often used to denote a group of concepts in generic programming? As in "category tags."
?? Each standard iterator category denotes a single concept, as I understand it. The concepts happen to form a refinement hierarchy, but I don't see what that has to do with it.
3. In the traversal group/category of concepts, they should either *all* include the lexeme "traversal" or *none*.
Probably a good idea. We made that change to the tags, but not to the concept names.
Ok.
In fact, I propose to completely skip the "traversal" in the concept names. The only potential conceptual hurdle is the "access" in "random_access" (or RandomAccessIterator) that can be confused with the access-related group of concepts...
Bad idea, IMO. incrementable_tag, for example, shouldn't be reserved by an iterators library; it could apply to lots of things.
I agree with that cross-group applicability of the tag, but what has that insight to do with skipping "traversal" in the concept names?
The words single-pass or bidirectional will have different meanings in different contexts.
4. The access group of iterator concepts: what is so "iterative" about them? I.e., are they not general proxy concepts, with potential applications in smart pointers and other proxy situations?
...and your point is...?
Exactly the point you made in your last comment, namely, that "it could apply to lots of things."
They were designed so that they could be used independently from traversal.
That was the point I was making...
I don't think the requirements on a a "readable" file should neccessarily be the same as those on a "readable" iterator. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David (Abrahams), First of all, I am excited that your proposal has been formally excepted into the TR, since the dichotomy of yours is the way to go. The reason for me to stay at the naming of things is to make you understand that there is a slight possibility of even quite skilled individuals being led astray by the terminology; as to perhaps clarify certain notions in forthcoming revisions. Ok, you saw that there are two orthogonal issued pertaining to the iterator classifications, i.e., traversal and access. In your proposal, dated 1/19, under the section Design, you write: "The iterator requirements are to be separated into two groups. One set of concepts handles the syntax and semantics of value access ... The other set of concepts handles traversal" There you enumerate the various concepts in each "group" (you also use the word "set" later.)
From this I thought it would be safe to use the term "group of concepts" or "concept group" for "set of concepts" or "requirement groups."
So, the traversal concepts is one group and the access concepts another. You have to map these two orthogonal dimensions into the old, simple hierarchy. You choose to make the traversal concept group pivotal, e.g., you "do not provide tags for the purposes of dispatching based on the access concepts." That is fine. Since the old treatment of iterators dealt with only one dimension, they used the word "category." No need to be more specific "back then..." It is a bit confusing if we, in this new two-dimensional iterative world, use "category" *both* for the combined (intersected) concepts, being analogous to the old concepts, *and* for one of the dimensions. In our case, Traversal. We have to make the meta programming facilities, such as the tags used, be backward-compatible, with that I agree. So, we have to keep the "category tag" and "iterator category" and map them to something sensible. We just have to live with the categories, as realized by category tags, dealing *both* with unique combinations of the two orthogonal issues (backward compatibility etc.) *and* with only one of the issues, Traversal, I assume. Could one not make that clear, such as: "category tags can dispatch based on both traversal capability and the combined capabilities of traversal and access" I understand, and always understood, your proposal, which is very welcome, but I do also understand if others might find the mentioning of "category" a bit misleading, since we have the old, combined world, and the new dichotomy to deal with. And... one does, unfortunately, use the word "category" in generic programming for both a single concept and a family of related concepts, often including refinement hierarchies :-| I prefer the less charged word "set of concepts" that you used. Thanks, David
"David Bergman" <davidb@home.se> writes:
David (Abrahams),
First of all, I am excited that your proposal has been formally excepted into the TR, since the dichotomy of yours is the way to go. The reason for me to stay at the naming of things is to make you understand that there is a slight possibility of even quite skilled individuals being led astray by the terminology; as to perhaps clarify certain notions in forthcoming revisions.
Fine.
Since the old treatment of iterators dealt with only one dimension, they used the word "category." No need to be more specific "back then..."
It is a bit confusing if we, in this new two-dimensional iterative world, use "category" *both* for the combined (intersected) concepts, being analogous to the old concepts, *and* for one of the dimensions. In our case, Traversal.
We are not ever doing that, AFAIK. "Category" never refers to "Traversal" and always refers to old-style concepts/tags. If you know of a place in the text where that happens, please point to it.
We have to make the meta programming facilities, such as the tags used, be backward-compatible, with that I agree. So, we have to keep the "category tag" and "iterator category" and map them to something sensible.
We just have to live with the categories, as realized by category tags, dealing *both* with unique combinations of the two orthogonal issues (backward compatibility etc.) *and* with only one of the issues, Traversal, I assume.
Now I'm lost again.
Could one not make that clear, such as:
"category tags can dispatch
Tags don't dispatch, and I consider that phrase extremely confusing, and possibly misleading.
based on both traversal capability and the combined capabilities of traversal and access"
Besides that, I have no clue about the intended meaning of the above statement, so I wouldn't make it in an effort to clarify anything.
I understand, and always understood, your proposal, which is very welcome, but I do also understand if others might find the mentioning of "category" a bit misleading, since we have the old, combined world, and the new dichotomy to deal with.
I still don't understand what you consider misleading. Please point to a sentence and describe how it can be misread.
And... one does, unfortunately, use the word "category" in generic programming for both a single concept and a family of related concepts,
I've never heard that before, and I'm pretty well-versed in GP. If you could point me to an example in the literature, I'd be indebted.
often including refinement hierarchies :-| I prefer the less charged word "set of concepts" that you used.
I appreciate that you're only trying to be helpful, but I really can't understand you. Trying to figure out what you mean takes a lot of time. If you won't take this suggestion, Quote some text from the paper, say "I think it should say ________" instead, and then say why you think so. I don't think I'm going to spend much more time trying to figure out what you want. Sorry, -- Dave Abrahams Boost Consulting www.boost-consulting.com
David A wrote:
It is a bit confusing if we, in this new two-dimensional iterative world, use "category" *both* for the combined (intersected) concepts, being analogous to the old concepts, *and* for one of the dimensions. In our case, Traversal.
We are not ever doing that, AFAIK. "Category" never refers to "Traversal" and always refers to old-style concepts/tags. If you know of a place in the text where that happens, please point to it.
In the Design section of the proposal, you write "Our design reuses iterator_traits<Iter>::iterator_category to indicate an iterator's traversal capability." That use of iterator category does pertain to the Traversal "dimension" (attribute, or whatever we want to call it), or? I want there to be an explanation, such as "Our design reuses iterator_traits<Iter>::iterator_category to indicate not only the old-style, combined traversal and access capabilities of the iterator, but also the iterator's traversal capability alone. See the category-to-traversal schema for conversion from the old-style iterator categories to corresponding traversal capability categories. Note that the access capability of the iterator is not incorporated in any iterator category, but derivable from the associated value_type of the concept."
We have to make the meta programming facilities, such as the tags used, be backward-compatible, with that I agree. So, we have to keep the "category tag" and "iterator category" and map them to something sensible.
We just have to live with the categories, as realized by category tags, dealing *both* with unique combinations of the two orthogonal issues (backward compatibility etc.) *and* with only one of the issues, Traversal, I assume.
Now I'm lost again.
Some of of the 'iterator_trats::iterator_category' instances refer to traversal capabilities, as in the quoted text above, and some to the old-style concepts. I.e., there are new "iterator categories" that only treat the Traversal attribute/dimension.
Could one not make that clear, such as:
"category tags can dispatch
Tags don't dispatch, and I consider that phrase extremely confusing, and possibly misleading.
I obviously meant "category tags enable dispatching on both ..."
based on both traversal capability and the combined capabilities of traversal and access"
Besides that, I have no clue about the intended meaning of the above statement, so I wouldn't make it in an effort to clarify anything.
I meant that one can dispatch based solely on the traversal property of the iterator and the combined traversal and access properties.
I understand, and always understood, your proposal, which is very welcome, but I do also understand if others might find the mentioning of "category" a bit misleading, since we have the old, combined world, and the new dichotomy to deal with.
I still don't understand what you consider misleading. Please point to a sentence and describe how it can be misread.
See above. You still think you use "category" only for the combined old-style concepts?
And... one does, unfortunately, use the word "category" in generic programming for both a single concept and a family of related concepts,
I've never heard that before, and I'm pretty well-versed in GP. If you could point me to an example in the literature, I'd be indebted.
In the article http://www.oonumerics.org/tmpw01/willcock.pdf, co-written by Jeremy Siek, they use "category" very similar to how the C++ Standard deals with iterator categories (i.e., as axiomatic sets): In 4.1.1.1: "Each concept must have a name and optionally a category." Does "category" there not refer to a qualification being isomorphic to a family of concepts? Also, in the same article: In 4.3: "A concept is described within the scope of a concept tag which contains the concept name and the category of the concept (in this case \Utility" for STL utility concepts)." Thus, Utility is here an (axiomatic or not) family, or set, of concepts. A category... For (unfortunate) examples where "category" is used synonymous to "concept," look at the eminent book "Generative Programming," by Czarnecki and Eisenecker, where they (in A.1) state that "... in the context of categorization, concepts are often called categories or classes ..." So, "category" does carry a meaning in GP, and is not specific to the (old-style) C++ iterators.
often including refinement hierarchies :-| I prefer the less charged word "set of concepts" that you used.
I appreciate that you're only trying to be helpful, but I really can't understand you. Trying to figure out what you mean takes a lot of time. If you won't take this suggestion,
Quote some text from the paper, say "I think it should say ________" instead, and then say why you think so.
I don't think I'm going to spend much more time trying to figure out what you want.
I am quoting, and I hope you see that (A) you do use "iterator category" for both the old-style iterator classification and the pure traversal capability classification and (B) that "category" is used in GP for sets of (related) concepts. /David
[Jeremy, I hope you can comment on this because some of it relates to your writings] "David Bergman" <davidb@home.se> writes:
In the Design section of the proposal, you write
"Our design reuses iterator_traits<Iter>::iterator_category to indicate an iterator's traversal capability."
That use of iterator category does pertain to the Traversal "dimension" (attribute, or whatever we want to call it), or?
I want there to be an explanation, such as
"Our design reuses iterator_traits<Iter>::iterator_category to indicate not only the old-style, combined traversal and access capabilities of the iterator, but also the iterator's traversal capability alone. See the category-to-traversal schema for conversion from the old-style iterator categories to corresponding traversal capability categories. Note that the access capability of the iterator is not incorporated in any iterator category, but derivable from the associated value_type of the concept."
That's very comprehensible, and a good suggestion, thank you. The wording should be slightly different, but it's good.
Some of of the 'iterator_traits::iterator_category' instances refer to traversal capabilities, as in the quoted text above, and some to the old-style concepts. I.e., there are new "iterator categories" that only treat the Traversal attribute/dimension.
That's a stretch. We don't want to call traversal concepts "categories". They just happen to be indicated via the iterator_category member of iterator_traits.
Could one not make that clear, such as:
"category tags can dispatch
Tags don't dispatch, and I consider that phrase extremely confusing, and possibly misleading.
I obviously meant "category tags enable dispatching on both ..."
based on both traversal capability and the combined capabilities of traversal and access"
Besides that, I have no clue about the intended meaning of the above statement, so I wouldn't make it in an effort to clarify anything.
I meant that one can dispatch based solely on the traversal property of the iterator and the combined traversal and access properties.
Actually no, not directly. If you want to dispatch on traversal you have to use iterator_traversal<It>::type to get at the traversal property. Old-style iterators' iterator_category doesn't have any convertibility relationship to the traversal tags.
I understand, and always understood, your proposal, which is very welcome, but I do also understand if others might find the mentioning of "category" a bit misleading, since we have the old, combined world, and the new dichotomy to deal with.
I still don't understand what you consider misleading. Please point to a sentence and describe how it can be misread.
See above. You still think you use "category" only for the combined old-style concepts?
Yes. "category" (roman font) and "iterator_category" (typewriter font) are two different ideas.
And... one does, unfortunately, use the word "category" in generic programming for both a single concept and a family of related concepts,
I've never heard that before, and I'm pretty well-versed in GP. If you could point me to an example in the literature, I'd be indebted.
In the article http://www.oonumerics.org/tmpw01/willcock.pdf, co-written by Jeremy Siek, they use "category" very similar to how the C++ Standard deals with iterator categories (i.e., as axiomatic sets):
In 4.1.1.1: "Each concept must have a name and optionally a category."
Does "category" there not refer to a qualification being isomorphic to a family of concepts?
Also, in the same article:
In 4.3: "A concept is described within the scope of a concept tag which contains the concept name and the category of the concept (in this case \Utility" for STL utility concepts)."
Thus, Utility is here an (axiomatic or not) family, or set, of concepts. A category...
I guess so, though I think when you get to the example use of "Utility", there's no real relationship among family members. This usage, however, has not caught on in GP AFAICT even though it is the normal meaning of "category". Its intersection with "iterator_category" is an unfortunate accident caused by the original STL design, and I don't think it should be up to the Boost iterator docs to try to clear it up.
For (unfortunate) examples where "category" is used synonymous to "concept," look at the eminent book "Generative Programming," by Czarnecki and Eisenecker, where they (in A.1) state that
"... in the context of categorization, concepts are often called categories or classes ..."
So, "category" does carry a meaning in GP, and is not specific to the (old-style) C++ iterators.
Maybe we just need to say at the beginning that when we refer to "iterator categories" we mean the old-style concepts?
often including refinement hierarchies :-| I prefer the less charged word "set of concepts" that you used.
I appreciate that you're only trying to be helpful, but I really can't understand you. Trying to figure out what you mean takes a lot of time. If you won't take this suggestion,
Quote some text from the paper, say "I think it should say ________" instead, and then say why you think so.
I don't think I'm going to spend much more time trying to figure out what you want.
I am quoting
It worked brilliantly, thank you!
, and I hope you see that (A) you do use "iterator category" for both the old-style iterator classification and the pure traversal capability
Nope, we never use it for pure traversal.
classification and (B) that "category" is used in GP for sets of (related) concepts.
It looks like "category" has a confusing usage in the literature, but I don't know how/what we should do about it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
Angus Leeming -
David Abrahams -
David Bergman