Section 21

How to Design Programs: An Introduction to Programming and Computing

Info iconThis preview shows pages 1–3. 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 21 Designing Abstractions from Examples When we first learn to add, we use concrete examples. Later on, we study how to add two arbitrary numbers; that is, we form an abstraction of the addition operation. Much later still, we learn to formulate abstractions directly as expressions: expressions that compute the wage of some employee, expressions that convert temperatures, or expressions that determine the area of a geometric shape. In short, we initially go from concrete examples to abstraction, but eventually we learn to form abstractions directly without thinking (much) about concrete instances. In this section, we discuss a design recipe for creating abstractions from concrete examples. Later, in sections 21.5 and 22 we study additional approaches to function abstraction. 21.1 Abstracting from Examples Forming abstractions from examples is easy. As we have seen in section 19 , we start from two concrete function definitions, compare them, mark the differences, and abstract. Let us formulate these steps as a recipe: The comparison: When we find two function definitions that are almost the same except at a few places and for their names, we compare them and mark the differences with boxes. If the boxes contain only values, we can abstract. Warning: Abstracting over Non-values : The recipe requires a substantial modification for non-values. Here is a pair of similar function definitions: ;; convertCF : lon -> lon (define (convertCF alon) (cond [(empty? alon) empty] [else (cons ( C->F (first alon)) (convertCF (rest alon)))])) ;; names : loIR -> los (define (names aloIR) (cond [(empty? aloIR) empty] [else (cons ( IR-name (first aloIR)) (names (rest aloIR)))])) The two functions apply a function to each item in a list. They differ in only one aspect: what they apply to each item on the list. The two boxes emphasize the difference. Each contains a functional value, so we can abstract. The abstraction: Next we replace the contents of corresponding pairs of boxes with new names and add these names to the parameter list. For example, if there are three pairs of boxes, we need three new names. The two definitions must now be the same, except for the function name. To obtain the abstraction, we systematically replace the function file:///C|/Documents%20and%20Settings/Linda%20Graue. ..How%20to%20Design%20Programs/curriculum-Z-H-27.html (1 of 12) [2/5/2008 4:50:32 PM]
Background image of page 1

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

View Full Document Right Arrow Icon
How to Design Programs: An Introduction to Computing and Programming names with one new name. For our running example, we obtain the following pair of functions: (define (convertCF f alon) (cond [(empty? alon) empty] [else (cons ( f (first alon)) (convertCF f (rest alon)))])) (define (names f aloIR) (cond [(empty? aloIR) empty] [else (cons ( f (first aloIR)) (names f (rest aloIR)))])) We have replaced the boxed names with f and added f as a parameter. Now we replace
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

Page1 / 12

Section 21 - How to Design Programs An Introduction to...

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

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