3 ms·

That's basically the 'you probably don't actually want to do that' answer that i mentioned at the end of my comment. I don't think its a good answer in the cont

That's basically the 'you probably don't actually want to do that' answer that i mentioned at the end of my comment. I don't think its a good answer in the context we are discussing: 1. If you gave this response to the hypothetical five year old, you will simply make them cry, and then they will quit programming. 2. If you give this response to the hypothetical fifty year old, they will feel you're hemming and hawing to cover a weakness in the language rather than giving a more direct and honest answer. In regards to (2), I'm not literally a 50 year old learning Haskell, but I am an adult teaching himself how to program for the first time, starting with Standard ML. Perhaps if you have a few minutes you'd be willing to let me elaborate on my complaint and check my understanding? The main issue i'm imagining is modeling homogeneous data vs heterogeneous data. With tuples, the types of data are encoded in the tuple type, and are known at compile time. In SML its a product, so a tuple of length 2 is a different type then one of length 3. Presumably this is what you meant by 'not really collection types'? Tuples of different lengths having different types is, if i'm understanding things correctly, the key point for this discussion. If i want to write a mythic 'tuple length' function in SML, it has to be generic enough to work on something of type a->int, and a* b->int, and a* b* c->int, etc... And so it has to make sense for any 'a->int (where 'a is a variable), which is to say it can't know anything about the structure of tuples! Is this reasoning correct? Assuming it is, you can see why I called those answers 'hemming and hawing'. This is clearly not something put in the language based on some prior logic about indices or collections or fixed sizes...nobody wants to not be able to write functions from arbitrary tuples; it appeared as a design trade off in order to access type information at compile time. It also is not specific to the length function. A second strategy to model heterogeneous data is to use a homogeneous collection like a list but then use a sum type to introduce heterogenity. This makes a different trade off: the types are the same for different sizes so we can write functions easily (including length!) but the types are the same so we've lost access to compile time information, and the class checks from the sum are done at run time. Thanks for taking the time to read this far and correct my misconceptions!

jolux 8y ago
It’s just the definition of a tuple. Having fixed length and tuples of different lengths being different types is important because it means you can pattern match on them and from that you also get things like destructuring and so on and so forth that you do not have with lists. You can call it a limitation but it’s more just about the design philosophy of a tuple. You can get the nth element by pattern matching, which you cannot do with growable data structures. You probably do not want a function that operates on all tuples in the first place, because making that possible massively reduces their utility for places where they are useful in the first place. Basically, use a different/real collection type if you need to do this. Tuples offer specific features that other types do not have and are constrained in their utility because of this. Records and arrays are often a better choice.

jolux 8y ago

It’s just the definition of a tuple. Having fixed length and tuples of different lengths being different types is important because it means you can pattern match on them and from that you also get things like destructuring and so on and so forth that you do not have with lists. You can call it a limitation but it’s more just about the design philosophy of a tuple. You can get the nth element by pattern matching, which you cannot do with growable data structures. You probably do not want a function that operates on all tuples in the first place, because making that possible massively reduces their utility for places where they are useful in the first place. Basically, use a different/real collection type if you need to do this. Tuples offer specific features that other types do not have and are constrained in their utility because of this. Records and arrays are often a better choice.