David Abrahams wrote:

Joel de Guzman <joel@boost-consulting.com> writes:

...

Hi,

Ok, as promised. Support for classic boost::tuple has been added. Now yer ole boost tuples are full fusion citizens. Now boost::tuple can do for_each, transform, fold, find, assign/convert to other fusion sequences, etc.

Now there are 3 adapted sequences: 1) std::pair

This one is going to cause me issues. I'm writing a unified library to operate on static and dynamic sequences. Here's the issue: is

pair<int*,int*>

a dynamic sequence that goes from the first pointer to the 2nd (as in Boost.Range), or a static sequence with 2 elements (a la Fusion)?

Both? I think, in as much as boost::array<int> is a dynamic sequence that STL algorithms can operate on, and at the same time, is also a static sequence fusion algorithms can handle, the same should be true for mono-sequences like pair<int*,int*>. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Joel de Guzman <joel@boost-consulting.com> writes:

David Abrahams wrote:

...

Joel de Guzman <joel@boost-consulting.com> writes:

...

Hi,

Ok, as promised. Support for classic boost::tuple has been added. Now yer ole boost tuples are full fusion citizens. Now boost::tuple can do for_each, transform, fold, find, assign/convert to other fusion sequences, etc.

Now there are 3 adapted sequences: 1) std::pair

This one is going to cause me issues. I'm writing a unified library to operate on static and dynamic sequences. Here's the issue: is

pair<int*,int*>

a dynamic sequence that goes from the first pointer to the 2nd (as in Boost.Range), or a static sequence with 2 elements (a la Fusion)?

Both? I think, in as much as boost::array<int> is a dynamic sequence that STL algorithms can operate on, and at the same time, is also a static sequence fusion algorithms can handle, the same should be true for mono-sequences like pair<int*,int*>.

[what's a mono-sequence?] It's not the same thing at all. In the case of array<int>, the sequence has the same elements in either case; we're just talking about two ways of accessing the same sequence. In the case of std::pair there are two completely distinct interpretations, either of which could be valid. In my case I think there are only two possible choices: 1. say that std::pair needs to be wrapped or otherwise transformed before I know how to treat it. 2. pick one of the two interpretations. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Joel de Guzman <joel@boost-consulting.com> writes:

...

[what's a mono-sequence?]

The opposite of hetero-sequence :P

A mono-sequence is the opposite of a multi-sequence. The opposite of a hetero-sequence is a homo-sequence.

...

It's not the same thing at all. In the case of array<int>, the sequence has the same elements in either case; we're just talking about two ways of accessing the same sequence. In the case of std::pair there are two completely distinct interpretations, either of which could be valid. In my case I think there are only two possible choices:

1. say that std::pair needs to be wrapped or otherwise transformed before I know how to treat it.

2. pick one of the two interpretations.

I'm sorry. I think I'm lost. With:

pair<int*,int*>

or

tuple<int*,int*,int*,int*>

or

array<int*>

I see the same elements. What am I missing?

* Boost.Range and Boost.Fusion both interpret an int*[4] as a sequence of 4 values of type int*. Consistent * Boost.Fusion interprets a pair<int*,int*> as a sequence of two values of type int*. * Boost.Range interprets a pair<int*,int*> x as a sequence of x.second-x.first values of type int. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Joel de Guzman wrote:

David Abrahams wrote:

...

* Boost.Fusion interprets a pair<int*,int*> as a sequence of two values of type int*.

* Boost.Range interprets a pair<int*,int*> x as a sequence of x.second-x.first values of type int.

Oh man, Now I see the problem. Pardon my slowness!!! Well, it seems, this interpretation of Boost.Range for pair<T*,T*> (or in general, std::pair<iterator,iterator> is at the very least suspicious. If we all agree that pair<T,T> is a tuple (a sequence in Fusion's sense), then pair<T*,T*> shouldn't be any different. I'd say that treating std::pair<iterator,iterator> as a runtime sequence is the wrong generalization.

It cannot be helped. std::equal_range returns a std::pair<iterator,iterator>. You'll have to argue with Stepanov about it. -- Eric Niebler Boost Consulting www.boost-consulting.com

Joel de Guzman <joel@boost-consulting.com> writes:

...

* Boost.Range and Boost.Fusion both interpret an int*[4] as a sequence of 4 values of type int*. Consistent

* Boost.Fusion interprets a pair<int*,int*> as a sequence of two values of type int*.

* Boost.Range interprets a pair<int*,int*> x as a sequence of x.second-x.first values of type int.

Oh man, Now I see the problem. Pardon my slowness!!! Well, it seems, this interpretation of Boost.Range for pair<T*,T*> (or in general, std::pair<iterator,iterator> is at the very least suspicious. If we all agree that pair<T,T> is a tuple (a sequence in Fusion's sense), then pair<T*,T*> shouldn't be any different. I'd say that treating std::pair<iterator,iterator> as a runtime sequence is the wrong generalization.

I disagree. There's no "wrong" here. It's going to be very common that in two different well-designed generic libraries, one 3rd party type plays different two different roles. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Joel de Guzman wrote:

Hence, pair<iterator,iterator> is just a collection of 2 iterators, nothing more.

Agreed. In pair<iterator, iterator> copy_n( iterator in, iterator out, size_t n ); the return value is not a range. copy_n just returns two iterators.

David Abrahams wrote:

Joel de Guzman <joel@boost-consulting.com> writes:

...

Here's another problem:

std::map<int*, int*> m;

generic code that treats pair<int* int*> as an iterator_range will treat m's data type incorrectly.

No, generic code doesn't look at types and say, "which of two concepts with no refinement relationship does this type fulfill?" and then take different actions based on the answer.

Sometimes it does. Consider serialization, or stream output. You could have if( type is a range ) output sequence of values else output something else Treating pair<pointer, pointer> as a range creates an ambiguity here.

On Fri, Sep 29, 2006 at 11:58:48AM -0400, David Abrahams wrote:

Joel de Guzman <joel@boost-consulting.com> writes:

...

Here's another problem:

std::map<int*, int*> m;

generic code that treats pair<int* int*> as an iterator_range will treat m's data type incorrectly.

No, generic code doesn't look at types and say, "which of two concepts with no refinement relationship does this type fulfill?" and then take different actions based on the answer. The only such type-based dispatching in generic code comes through algorithm specialization: "this type fulfills concept X, but also concept Y which is a refinement of X, so I'll use that information to do whatever I was going to do more efficiently."

The problem here is that there is one concept, namely a runtime sequence, that pair<int*,int*> fulfills in two unrelated ways. So generic code does need to be able to decide which way to interpret it. Or the concepts of iterator_range and runtime sequence have to be separated, which is unfortunate, since iterator_range is a very natural refinement of a runtime sequence. Geoffrey

David Abrahams wrote:

Joel de Guzman <joel@boost-consulting.com> writes:

...

To me it's like, generalizing that something with a wing, a propeller, and all things that comprise an airplane-- is an airplane. No, not necessarily. The presence of these elements do not complete the picture. It can be, say, *just a collection of parts*. Hence, pair<iterator,iterator> is just a collection of 2 iterators, nothing more.

External, non-intrusive, adaptation of a 3rd party type to make it model a particular concept that it doesn't model "inherently" is a fundamental generic programming maneuver. I don't see anything particularly wrong with making a pair of iterators model Range.

Jeremy Siek has described cases to me wherein one type can play two different roles with the *same* library. For that you need two different concept maps, to map the type into its different roles. Thus his recent "scoped concept_map" proposal.

Example please? The thing is, conceptually speaking, the pair has a very specific and well defined purpose (http://www.sgi.com/tech/stl/pair.html): ''' Pair<T1,T2> is a heterogeneous pair: it holds one object of type T1 and one of type T2. A pair is much like a Container, in that it "owns" its elements. It is not actually a model of Container, though, because it does not support the standard methods (such as iterators) for accessing the elements of a Container. ''' By "container", it's very clear that it models the tuple definition. It just so happens that STL does not have facilities for hetero-sequences. That is the domain of Fusion; and, as an STL extension, it fulfills that primary intent. It is also clear that the definition of pair does not, in any way, have anything to do with iterator ranges. I may grok what you say that there's no "wrong" here; it depends on the POV. However, if there is a conflict in definition such as in this case, it is my thinking that, for all intents and purposes, the definition that more closely follows the original intent, in the exact domain that it extends, has to take priority. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Hi Guys, On Sep 29, 2006, at 10:25 AM, David Abrahams wrote:

Joel de Guzman <joel@boost-consulting.com> writes:

...

To me it's like, generalizing that something with a wing, a propeller, and all things that comprise an airplane-- is an airplane. No, not necessarily. The presence of these elements do not complete the picture. It can be, say, *just a collection of parts*. Hence, pair<iterator,iterator> is just a collection of 2 iterators, nothing more.

External, non-intrusive, adaptation of a 3rd party type to make it model a particular concept that it doesn't model "inherently" is a fundamental generic programming maneuver. I don't see anything particularly wrong with making a pair of iterators model Range.

Yes. I also agree with Joel's position on airplanes (I misunderstood what he was saying at first... but yes, a pile of airplane parts is not an airplane), which is why I've always been in favor of explicit concept conformance. I see the concept_map declaration as the final touch that turns the parts into an airplane.

Jeremy Siek has described cases to me wherein one type can play two different roles with the *same* library. For that you need two different concept maps, to map the type into its different roles. Thus his recent "scoped concept_map" proposal.

Think of a variant of the accumulate function that instead of having parameters for an initial object and function object, requires the value_type of the iterators to be a model of Monoid... which just requires a binary operator and an initial object that is an identity with respect to the binary operator. The type "int" could model Monoid many ways. For example, it could use "+" for the binary operator and "0" for the initial object. It could also use "*" for the binary operator and "1" for the initial object.

...

All that being said, I don't care too much either way. It's not a concern of Fusion, AFAICT. Unless, you are asking for std::pair to be removed from the list of supported Fusion sequences?

Nope. Just raising the point for discussion.

I think the main thing to take away from this is that scoped concept maps are good. They allow you to have it both ways, in different parts of your program. And yes, we could solve the problem by requiring wrappers, but wrapping stuff is a pain. Cheers, Jeremy __________________________________ Jeremy Siek <siek@cs.colorado.edu> http://www.cs.colorado.edu/~siek/ Visiting Assistant Professor Department of Computer Science University of Colorado at Boulder

Hi Joel, On Sep 30, 2006, at 10:31 PM, Joel de Guzman wrote:

I'd like to know more about scoped concept maps and how it can help in this scenario. Any pointers? Links?

Here's the URL for the paper. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2098.pdf Cheers, Jeremy __________________________________ Jeremy Siek <siek@cs.colorado.edu> http://www.cs.colorado.edu/~siek/ Visiting Assistant Professor Department of Computer Science University of Colorado at Boulder

On Oct 1, 2006, at 6:17 AM, David Abrahams wrote:

Jeremy Siek <jeremy.siek@gmail.com> writes:

...

I also agree with Joel's position on airplanes (I misunderstood what he was saying at first... but yes, a pile of airplane parts is not an airplane), which is why I've always been in favor of explicit concept conformance. I see the concept_map declaration as the final touch that turns the parts into an airplane.

That isn't even enough in this case. One pair<int*,int*> object is just a couple of pointers, while another is a sequence of ints. Scoped concept_maps get us closer, but I'm not sure it's fully general: you could still have both kinds of pair in the same code, right?

Not sure exactly what you're saying... perhaps the following makes it more clear. With scoped maps, you can have different concept maps in scope in different parts of your code. So if you're about to call an algorithm, and you want pair<int*,int*> to be treated a something with just 2 elements, you would import the concept map from fusion. Later on, in a different scope, if you want pair<int*,int*> to be treated as something with second-first elements, then you'd import the concept map from the range library. Cheers, Jeremy __________________________________ Jeremy Siek <siek@cs.colorado.edu> http://www.cs.colorado.edu/~siek/ Visiting Assistant Professor Department of Computer Science University of Colorado at Boulder

Hi Dave, On Oct 2, 2006, at 4:40 AM, David Abrahams wrote:

Sure. So, leaving aside that I have the syntax and probably a few other things wrong:

template <class T, Sequence<int*> S1, Sequence<T> S2, UnaryFunction<T,int*> F> void transform(S1 const& src, S2& dst, F f)

typedef std::pair<int*,int*> r;

template <Sequence<int> S1> std::pair<int*,int*> f(S1 s) { r ret;

// treat pair<int*,int*> as a sequence of int* concept_map<r, Sequence<int*> > { ... };

transform(s, ret, address()); }

int storage[2]; r input = { storage, storage+2 };

// Treat pair<int*,int*> as a sequence of int concept_map<r, Sequence<int> > { ... };

// OK? r x = f(input);

// which concept does x model?

It's early in the morning, but I'll do my best... In this outer scope, the type 'r' models Sequence<int>, so the call to f type checks. Inside of function f, 'S1' models Sequence<int> and 'r' models Sequence<int*>. The call to transform will not type check because the requirement Sequence<int*> S1 is not satisfied. Cheers, Jeremy __________________________________ Jeremy Siek <siek@cs.colorado.edu> http://www.cs.colorado.edu/~siek/ Visiting Assistant Professor Department of Computer Science University of Colorado at Boulder

----Original Message---- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel de Guzman Sent: 29 September 2006 00:25 To: boost@lists.boost.org Subject: Re: [boost] [fusion] Support for classic boost::tuple

David Abrahams wrote:

...

Joel de Guzman <joel@boost-consulting.com> writes:

...

...

Joel de Guzman <joel@boost-consulting.com> writes:

...

Hi,

Ok, as promised. Support for classic boost::tuple has been added. Now yer ole boost tuples are full fusion citizens. Now boost::tuple can do for_each, transform, fold, find, assign/convert to other fusion sequences, etc.

Now there are 3 adapted sequences: 1) std::pair This one is going to cause me issues. I'm writing a unified library to operate on static and dynamic sequences. Here's the issue: is

pair<int*,int*>

a dynamic sequence that goes from the first pointer to the 2nd (as in Boost.Range), or a static sequence with 2 elements (a la Fusion)? Both? I think, in as much as boost::array<int> is a dynamic sequence that STL algorithms can operate on, and at the same time, is also a static sequence fusion algorithms can handle,

David Abrahams wrote: the same should be true for mono-sequences like pair<int*,int*>.

[what's a mono-sequence?]

The opposite of hetero-sequence :P

...

It's not the same thing at all. In the case of array<int>, the sequence has the same elements in either case; we're just talking about two ways of accessing the same sequence. In the case of std::pair there are two completely distinct interpretations, either of which could be valid. In my case I think there are only two possible choices:

1. say that std::pair needs to be wrapped or otherwise transformed before I know how to treat it.

2. pick one of the two interpretations.

I'm sorry. I think I'm lost. With:

pair<int*,int*>

or

tuple<int*,int*,int*,int*>

or

array<int*>

I see the same elements. What am I missing?

Cheers,

I think the problem is, should pair<int*,int*> a_pair_of_pointers; be treated the same as int* two_pointers[2]; or the same as int an_array_of_ints[ pair.second-pair.first ] The first is the obvious answer if you treat the pair as a special form of tuple. The second is the obvious answer is you consider the pair as two iterators over a sequence (like the Boost Range library). -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894