Haskell/Solutions/Lists and tuples

Building lists

 * 1) This won't work. [True, False] is a list of booleans, 3 is an integer.
 * ,  and   are all valid functions.
 * 1)   returns
 * 2)   returns
 * 3)   gives a type error. This is the same mistake as in exercise 1.
 * 4)   gives no output message, but foo is  . Try it!
 * 5)   (assuming you did 2.4) returns
 * 6) As recognized   does not work, cause 8 is not a list, but   will work since (++) concatenates 2 lists
 * ,  are both valid functions.

Lists within lists

 * 1) 1 and 2 aren't valid Haskell, 3 is valid:
 * 2)  . ,   and   are integers, while   is a list.
 * 3)  . Again,   and   are integers, and   is a list of integers.
 * 4)  . This is valid Haskell, as   is a list of integers, and   is an empty list (of any type).
 * 5) The first four are valid Haskell. The fifth is not.
 * 6)  . Both   and   are lists of integers. The whole list is a list of lists of integers. We can cons an empty list (of any type) in front of it.
 * 7)  . Not the empty list!. This is a list containing an empty list. The list itself is not empty, because it has one element!
 * 8)  . This is a list containing two empty lists.
 * 9)  . This is the same list as the previous, but with a   as the first element instead of  . Since the list was a lists of lists, it now has become a list of list of integers.
 * 10)  . ["hi"] is a list of Chars while [1] is a list of integers.
 * 11) Yes, this is possible. For example:  . Why? You can make a list of anything! If you already have a list of some type, then you can make a list of lists of that type. The example list would be written as:
 * 12) The list   is not valid because it is equivalent to , where we try to cons elements that have different types (i.e. list and numeric). Lists in Haskell must be type-homogeneous. A valid list would be  , equivalent to.

A different notion of many

 * 1) They all are! Tuples aren't restricted to types.
 * 2) A tuple of two integers.
 * 3) A tuple of an integer and a string.
 * 4) A tuple of a boolean and two strings.
 * 5) The empty tuple   is pronounced "unit"
 * 6) Maybe the creators of Haskell wanted to limit the functionality of tuples to discourage their overuse. The practice of feeding functions cons-able tuples, instead of lists and tuples, may have made functions more complex, therefore harder to read, write and maintain.
 * 7) Unlike lists, we would obtain a tuple with a different type, because the tuple size would be bigger.
 * 1) Maybe the creators of Haskell wanted to limit the functionality of tuples to discourage their overuse. The practice of feeding functions cons-able tuples, instead of lists and tuples, may have made functions more complex, therefore harder to read, write and maintain.
 * 2) Unlike lists, we would obtain a tuple with a different type, because the tuple size would be bigger.

Tuples within lists and other combinations

 * 1) * Not valid.  is a tuple, and cons, , only works with lists.
 * 2) * Not valid.  is a tuple, and cons, , only works with lists.
 * 3) * Valid. You'll get a list of tuples of an integer and an integer:
 * 4) * Not valid. All elements of a list must be of the same type.  and   are tuples of an integer and an integer, but   is a tuple of a character and a character.
 * 5) * Valid. This is a tuple of a list of integers and a list of integers.
 * 1) * Valid. This is a tuple of a list of integers and a list of integers.

Retrieving values

 * 1)   returns.
 * 2) Yes, we can! The difference between a tuple and a list is that all elements of a list must be of the same type (integers, booleans, etc.), but you can add elements to the list. The elements of a tuple can be of any type you want, like a tuple of an integer and a character in , but you can't change its size.
 * 3)   Inconveniences of this implementation include the clunkiness of the definition, its lack of generality (what if we wanted to get the fourth or the sixth or the nineteenth element?), and the fact it will cause the program to crash whenever it is passed a list with less than five elements.
 * 1)   Inconveniences of this implementation include the clunkiness of the definition, its lack of generality (what if we wanted to get the fourth or the sixth or the nineteenth element?), and the fact it will cause the program to crash whenever it is passed a list with less than five elements.