{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

Section 19

# How to Design Programs: An Introduction to Programming and Computing

This preview shows pages 1–2. Sign up to view the full content.

How to Design Programs: An Introduction to Computing and Programming [Go to first , previous , next page; contents ; index ] Section 19 Similarities in Definitions Many of our data definitions and function definitions look alike. For example, the definition for a list of symbols differs from that of a list of numbers in only two regards: the name of the class of data and the words ``symbol'' and ``number.'' Similarly, a function that looks for a specific symbol in a list of symbols is nearly indistinguishable from one that looks for a specific number in a list of numbers. Repetitions are the source of many programming mistakes. Therefore good programmers try to avoid repetitions as much as possible. As we develop a set of functions, especially functions derived from the same template, we soon learn to spot similarities. It is then time to revise the functions so as to eliminate the repetitions as much as possible. Put differently, a set of functions is just like an essay or a memo or a novel or some other piece of writing: the first draft is just a draft. Unless we edit the essay several times, it does not express our ideas clearly and concisely. It is a pain for others to read it. Because functions are read by many other people and because real functions are modified after reading, we must learn to ``edit'' functions. The elimination of repetitions is the most important step in the (program) editing process. In this section, we discuss similarities in function definitions and in data definitions and how to avoid them. Our means of avoiding similarities are specific to Scheme and functional programming languages; still, other languages, in particular object-oriented ones, support similar mechanisms for factoring out similarities -- or (code) patterns as they are somtimes called. 19.1 Similarities in Functions The use of our design recipes entirely determines a function's template -- or basic organization -- from the data definition for the input. Indeed, the template is an alternative method of expressing what we know about the input data. Not surprisingly, functions that consume the same kind of data look alike. ;; contains-doll? : los -> boolean ;; to determine whether alos contains ;; the symbol 'doll (define (contains-doll? alos) (cond [(empty? alos) false] [else (cond [(symbol=? (first alos) 'doll) true] [else (contains-doll? (rest alos))])])) ;; contains-car? : los -> boolean ;; to determine whether alos contains ;; the symbol 'car (define (contains-car? alos) (cond [(empty? alos) false] [else (cond [(symbol=? (first alos) 'car) true] [else (contains-car? (rest alos))])])) Figure 52: Two similar functions Take a look at the two functions in figure 52 , which consume lists of symbols (names of toys) and look for specific toys. The function on the left looks for 'doll , the one on the right for 'car in a list of symbols (los). The two functions are nearly indistinguishable. Each consumes lists of symbols; each function body consists of a cond -expressions with two clauses. Each produces false if the input is empty ; each uses a second, nested cond -expression to determine whether file:///C|/Documents%20and%20Settings/Linda%20Graue...How%20to%20Design%20Programs/curriculum-Z-H-25.html (1 of 12) [2/5/2008 4:49:36 PM]

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}