Section 19

How to Design Programs: An Introduction to Programming and Computing

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

View Full Document Right Arrow Icon
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
Background image of page 1

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

View Full DocumentRight Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

This test prep was uploaded on 02/06/2008 for the course CS 1102 taught by Professor Fisler during the Spring '07 term at WPI.

Page1 / 12

Section 19 - How to Design Programs: An Introduction to...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online