I went through part of the tutorial on the Haskell website, and it seems like they use collections for storing data about objects (by that I mean if you want a "Person" object, you the first item of the list would be the age, and the second would be the name, like (36, "John")). Why do functional programmers do this? (@bh) Wouldn't it be easier to just create a 2D list and do a lookup from there, or use a hash table?
Not a Haskell programmer, so I'm not sure how to answer this, except to say that an aggregate type as seen by the user doesn't tell you how it's implemented. So a Python dictionary, for example, may well be implemented as a hash table -- very likely, if it offers constant-time access. You wouldn't want users to have to know how a hash table works, or look for medium-sized prime numbers to use as the table length, etc.
Umm, that doesn't help me. I know how to do it in Lisp, but you asked about Haskell, and I'm assuming a "collection" is a term of art in Haskell, not just "a set but with duplicates allowed" as it sometimes is in math.
"collection" isn't a term, I just used that since I was unsure whether you would say "list" or "tuple".
Oh I see. For me, a lot depends on how complex the data type is. For example, if what I want is a point, with components X and Y, building some complicated OOPy thing isn't worth it. I'd just use a list of length 2, and write selectors X-coordinate = item 1 of point and Y-coordinate = item 2 of point.
But if I have something with a dozen parts, and especially if different ones have different kinds of parts declared dynamically, then I'd build something like the Chapter VIII objects from the Reference Manual. And if this were a production language rather than an educational language, we'd have dozens of libraries with this sort of thing, the way JS and Python and Common Lisp do.