# [plt-scheme] Was HTDP 21.1.2 - Why I "don't" use the designrecipe, etc.

>>*
*>>*Maybe I should ask the question that struck me immediately I saw this
*>>*problem. Why would I want to do this anyway. Map and fold are clearly
*>>*intuitive one is a translation the other is a summarisation. I cannot
*>>*intuitively see why I would want to implement a translation in terms of a
*>>*summarisation.
*>*
*>*Perhaps because you were in an environment that provided one and not the
*>*other? That kind of thing certainly happens in the real world.
*>*
*>*Of course, the real, pedagogical reason for the problem is to expand the
*>*reader's conception of higher-order functions and their applicability. To
*>*point out that "fold" CAN be usefully used with S and T being different
*>*types -- exactly the lesson you're trying to learn.
*>*
*>>>*Once again, the X's and Y's in the contract for fold are independent
*>>>*from the X's and Y's for map, and we could instantiate it ...
*>>>*...snip...
*>>>*The names don't matter at all; in fact, we could instead use the names S
*>>>*and T:
*>>>*
*>>>*;; fold : forall S, T . T (S T -> T) [Listof S] -> T
*>>*
*>>*I would more readily accept this with an example of a case where we
*>>*summarised 2 different types of data - but lets see.
*>*
*>*Well, "map" is a good example, but that's what you're having trouble with
*>*already. Let's try a more prosaic example: use "fold" to write a
*>*"highest-salary" function on a list of employees. The input is a list of
*>*employees, so S must be "employee"; the output is a number, so T must be
*>*"number".
*>*
*
(define (fold op baseCase a-list)
(cond
[(empty? a-list) baseCase]
[else (op (first a-list)
(fold op baseCase (rest a-list)))]))
(define-struct emp (name salary))
(define (highestSalary emps)
(fold >emp 0 emps))
;>emp : employee number -> number
;returns the greater of the employees salary and the number
(define (>emp x y)
(cond
[(< (emp-salary x) y) y]
[else (emp-salary x)]))
Map is not yet obvious ..but I'm thinking of breakfast.