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
On Fri, Jul 10, 2009 at 11:26 AM, Joel de
Guzman wrote:
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
