Is there a benefit to specifically reserving varied data-type pairings for tuples like such:
[(23, \"Jordan\"), (8, \"Bryant\")]
As opposed
This question should have probably been more clearly stated as:
Why must we insist on the definition of a list as a collection of elements of exactly one type?
From one point of view the answer could be that it allows us to reason about lists in a rigorous way and a whole new class of operations become possible. Ex. how else would you define map
for lists?
From another point of view, if lists could hold multple types then the language could not have been staticly typed. Ex. if you are passed a list as an argument what is the type of head element?
You don't have this problem with tuples because you define the type of each element a priori and the length is fixed.
Is there a benefit to specifically reserving varied data-type pairings for tuples...
It is absolutely necessary for a statically typed language that lists hold elements of exactly one type, so the question of benefit has no benefit.
"Is there a benefit to specifically reserving varied data-type pairings for tuples like such:"
Yes. The benefits to the use of tuples are related to the usage patterns around the data and any performance requirements.
Tuples are often immutable and have a predictable size.
Since you're writing a haskell program, your lists of "strings and integers" are actually a list of a union type (call it whatever you want)... your tuple is just a special case.
This point is a bit more clear if you think about this as python code. (Both strings you provide are valid python code; I originally thought the question was python related)
In python, you would prefer the List of Tuples if you knew that the tuples had a fixed (or predictable) structure.
That would let you write code like:
[ print(name) for jersey, name in list_of_tuples ]
You would choose to use the tuple if you believed that paying for the price of an object representation wasn't worth it, and you preferred expressing every tuple reference with an unpacking.
Fortunately, since you're writing haskell, you have a number of tools to model and represent problems strongly in the type system. I think if you take a bit more time to read up and write some haskell (Learn you a Haskell for Great Good is a great book), you'll have a better understanding of the type system and you'll find the answer for this yourself.
If you're looking to learn more about functional programming in general, The Little Schemer is also spectacular.
((un)Fortunately, in python you can write code that handles both types of data structures, instead of worrying about the types going into the code. Haskell requires you to think a bit differently than that.)
Why do we use tuples, if we can use a two dimensional list?
Because lists and tuples are conceptually different things, and the type system gives us an useful way to state and recognise the difference in code. For one of many possible examples, one might define...
type ListyPair a = [a]
... and then...
listyFst :: ListyPair a -> a
listyFst [x, _] = x
listySnd :: ListyPair a -> a
listySnd [_, y] = y
... so that:
GHCi> listyFst [3,4]
3
GHCi> listySnd [3,4]
4
But what happens if the listy "pair" has just one element, or none? We would have to throw a runtime error (yuck), or make listyFst
and listySnd
result in a Maybe a
so that we can handle failure cleanly. What if the "pair" has more than two elements? Should we just discard them silently, or would it be better to make the functions fail in this case as well?
From the perspective of a strong type system user, when we replace an actual pair with ListyPair
we are throwing away useful information. Knowing that there are really just two elements allows us to avoid all of the complications above.
realFst :: (a, b) -> a
realFst (x, _) = x
realSnd :: (a, b) -> b
realSnd (_, y) = y