On Fri, Jul 10, 2009 at 11:26 AM, Joel de Guzman<joel@boost-consulting.com> wrote:
Zachary Turner wrote:
This may cause some disagreements but I'm honestly not sure that I agree with the idea that tuples should behave like sequences. Most other languages that enable functional programming style explicitly disallow this, and for good reason.
Really? "explicitly"? Can you provide an example of a language that explicitly states this and the reasons why? I didn't say they explicitly wrote in the standard "tuples cannot be treated as sequences by design", I said that it was a conscious design decision not to allow tuples to be treated as sequences. Lisp is the exception which I forgot about, if there are other widely used functional languages that allow one to treat tuples as sequences that I'm not aware of then I'd be interested to know what they are.
For starters, the word "sequence" implies (in the mathematical sense) that there is a possibility of the length being unbounded. While one could argue that it's possible to design a tuple class that could hold a number of elements bounded only by the amount of memory in one's computer (which for all intents and purpose we can consider an infinite tuple), a programmer can only define a finite number of types, so there must exist at least one type in the tuple that has values occuring an infinite number of times. So this begs the question of why not change the design of the application, and group similar types together. After all, if you've actually _specified_ an infinite number of values of said types to put into said tuple, then there is necessarily a relation between the values, or a formula if you will allowing one to generate them. 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