Re: [Boost-users] [Tuple] What's the point?

On Fri, Jul 10, 2009 at 12:52 PM, JOAQUIN M. LOPEZ MUÑOZ wrote:

________________________________________ De: boost-users-bounces@lists.boost.org [boost-users-bounces@lists.boost.org] En nombre de Zachary Turner [divisortheory@gmail.com] Enviado el: viernes, 10 de julio de 2009 19:44 Para: boost-users@lists.boost.org Asunto: Re: [Boost-users] [Tuple] What's the point?

...

I consider it a C++ design problem that there are actually situations where iterating over elements of a tuple is the "quickest" way to accomplish something.  When you're iterating over a collection and performing some operation on the items in the collection, the elements neecssarily having something in common otherwise the operation wouldn't make sense.  But at the same time, the common aspect is determined by the function, not by any aspect of the types themselves.  From a theoretical perspective I think it's better to approach this with typeclasses

C++0x concepts are very akin to type classes.

That's true, and they help in some ways. But it doesn't address other aspects. I suppose my complaint with iterating over tuples is mostly of a theoretical nature and maybe nobody really cares. But even so, I think that tuples should be completely distinct from sequences, and that anyone using a tuple should be required to know exactly how many elements are in it, and the type of every element in order for it to be possible to use the tuple. In a sense, allowing generic iteration over the elements of a tuple allows one to treat different tuples (including tuples of different lengths) as the same type, or at the very least being able to use two tuples of different types without realizing they're different types. Once variadic templates are more widely supported, then I think there will be even less of a case for "tuple-sequences", because most (all?) of the things it makes simpler can be achieved more naturally with v-templates. If you have an arbitrarily sized collection of objects, then there should at least be some kind of well-defined structure connecting the types to each other. If you're going to iterate over these elements and then perform a completely different action on each item, then obviously you need to know what the individual items are to select the appropriate action. On the other hand, if you're not going to be performing a completely different action on them, but rather performing the same action on all of them, then perhaps the action you're trying to perform should accept the tuple as its argument and let it decide what to do with each item. Of course, it will in turn need to make the same decision, and either understand the structure or pass it to something that does.

On Fri, Jul 10, 2009 at 11:26 AM, Joel de Guzman wrote:

...

functional languages if you need to manually operate on each element of a tuple other methods are provided like matching. I actually think that it might be possible to achieve some matching like constructs in C++, but I don't think (?) much if any research has been devoted to that.

Erm... every sentence above begs the question: why?

? I'm not sure what you mean by this sentence begging the question of why. If you know of any research that has been done regarding match constructs in C++ then please refer me to it. But the reason I don't think much has been done is because I've never heard of any. OTOH I don't claim to be aware of everything going on in the C++ world, so I'd be interested to read any such research you know of. That being said, given the amount of progress that has been been made regarding conditional constructs in lambda expressions, I think such techniques could be extended to allow for matching as well. A match is generally specified much like a switch statement anyway. For example, consider: boost::tuple test(4, 3.0, "hello, world"); using boost::tuple; using boost::tuple::match; using boost::tuple::pattern; using boost::tuple::_; match(test) | match_case( (7, _, _) -> (std::cout << "first arg is 7 and third arg is " << pattern::_3 << std::endl) ) | match_case( (_, 3.0, _) -> (std::cout << "second arg is 3.0" << std::endl) ) //this one will match | match_case( _ -> (std::cout << "no match!" << std::endl) ); It might even be possible to bind variables in the match condition, although I'm at a loss for how off the top of my head which is why I just made placehlders _1, _2, and _3. Anyway I haven't put a ton of thought into a workable, easy-to-read syntax that's technically possible, but something similar to the above should feasible. And a construct such as this is much clearer and easier to read / understand IMO than iterating over sequences of objects whose types presumably have nothing in common. It's true the above construct does not address the same problem that iterating over tuples addresses, but variadic templates pretty much do. I've yet to find a situation where boost::tuple made my life easier (apparently much like the original poster), so I only mention matching so much because IMO they are exactly what *would* make them useful.