## Section 2.2 Hierarchical Data and the Closure Property

Exercises in this section of SCIP.

**Exercise 2.17.** Define a procedure `last-pair`

that returns the list that contains only the last element of a given (nonempty) list:

1 | (last-pair (list 23 72 149 34)) |

**Answer 2.17.**

1 | (define (last-pair items) |

**Exercise 2.18.** Define a procedure `reverse`

that takes a list as argument and returns a list of the same elements in reverse order:

1 | (reverse (list 1 4 9 16 25)) |

**Answer 2.18.**

1 | (define (reverse items) |

**Exercise 2.19.** Consider the change-counting program of section 1.2.2. It would be nice to be able to easily change the currency used by the program, so that we could compute the number of ways to change a British pound, for example. As the program is written, the knowledge of the currency is distributed partly into the procedure `first-denomination`

and partly into the procedure `count-change`

(which knows that there are five kinds of U.S. coins). It would be nicer to be able to supply a list of coins to be used for making change.

We want to rewrite the procedure cc so that its second argument is a list of the values of the coins to use rather than an integer specifying which coins to use. We could then have lists that defined each kind of currency:

1 | (define us-coins (list 50 25 10 5 1)) |

We could then call cc as follows:

1 | (cc 100 us-coins) |

To do this will require changing the program `cc`

somewhat. It will still have the same form, but it will access its second argument differently, as follows:

1 | (define (cc amount coin-values) |

Define the procedures `first-denomination`

, `except-first-denomination`

, and `no-more?`

in terms of primitive operations on list structures. Does the order of the list `coin-values`

affect the answer produced by `cc`

? Why or why not?

**Answer 2.19.**

1 | (define (cc amount coin-values) |

**Exercise 2.20.** The procedures `+`

, `*`

, and list take arbitrary numbers of arguments. One way to define such procedures is to use define with *dotted-tail notation*. In a procedure definition, a parameter list that has a dot before the last parameter name indicates that, when the procedure is called, the initial parameters (if any) will have as values the initial arguments, as usual, but the final parameter’s value will be a *list* of any remaining arguments. For instance, given the definition

1 | (define (f x y . z) <body>) |

the procedure `f`

can be called with two or more arguments. If we evaluate

1 | (f 1 2 3 4 5 6) |

then in the body of `f`

, `x`

will be $1$, `y`

will be $2$, and `z`

will be the list `(3 4 5 6)`

. Given the definition

1 | (define (g . w) <body>) |

the procedure `g`

can be called with zero or more arguments. If we evaluate

1 | (g 1 2 3 4 5 6) |

then in the body of `g`

, `w`

will be the list `(1 2 3 4 5 6)`

.

Use this notation to write a procedure `same-parity`

that takes one or more integers and returns a list of all the arguments that have the same even-odd parity as the first argument. For example,

1 | (same-parity 1 2 3 4 5 6 7) |

**Answer 2.20.**

1 | (define (same-parity first . rest) |

**Exercise 2.21.** The procedure `square-list`

takes a list of numbers as argument and returns a list of the squares of those numbers.

1 | (square-list (list 1 2 3 4)) |

Here are two different definitions of `square-list`

. Complete both of them by filling in the missing expressions:

1 | (define (square-list items) |

**Answer 2.21.**

1 | (define (square-list items) |

**Exercise 2.22.** Louis Reasoner tries to rewrite the first `square-list`

procedure of exercise 2.21 so that it evolves an iterative process:

1 | (define (square-list items) |

Unfortunately, defining square-list this way produces the answer list in the reverse order of the one desired. Why?

Louis then tries to fix his bug by interchanging the arguments to `cons`

:

1 | (define (square-list items) |

This doesn’t work either. Explain.

**Answer 2.22.** The first procedure doesn’t work because it constructs the last item from the front of the list to the answer. The second procedure seems right at first glance, but result is:

`(square-list (list 1 2 3 4)) ((((() 1) 4) 9) 16)`

Let’s look the definition of `list`

:

1 | (list <a_1> <a_2> ... <a_n>) |

And the substitution of the procedure:

1 | (square-list (list 1 2 3 4)) |

Therefore, the structure of answer is wrong.

**Exercise 2.23.** The procedure `for-each`

is similar to `map`

. It takes as arguments a procedure and a list of elements. However, rather than forming a list of the results, `for-each`

just applies the procedure to each of the elements in turn, from left to right. The values returned by applying the procedure to the elements are not used at all – `for-each`

is used with procedures that perform an action, such as printing. For example,

1 | (for-each (lambda (x) (newline) (display x)) |

The value returned by the call to `for-each`

(not illustrated above) can be something arbitrary, such as true. Give an implementation of `for-each`

.

**Answer 2.23.** I find a feature between `cond`

and `if`

in Lisp. If we want to use `if`

instead of `cond`

, one things should be concerned. Here are definitions:

1 | (cond (<predicate> <expression> ...) |

In `cond`

, one clause has one predicate and several expressions, meanwhile consequent and alternative of `if`

only have one expression for each. Thus, in this exercise we should use `cond`

because `(newline)`

and `(display x)`

are two expressions.

```
(define (for-each f l)
(cond ((null? l) '())
(else (f (car l))
(for-each f (cdr l)))
)
)
```

**Exercise 2.24.** Suppose we evaluate the expression `(list 1 (list 2 (list 3 4)))`

. Give the result printed by the interpreter, the corresponding box-and-pointer structure, and the interpretation of this as a tree (as in figure 2.6).