In general, a program consists not just of one, but of many definitions.
The <#60464#><#1274#>area-of-disk<#1274#><#60464#> program, for example, consists of two
definitions: the one for <#60465#><#1275#>area-of-ring<#1275#><#60465#> and another one for
<#60466#><#1276#>area-of-disk<#1276#><#60466#>. We refer to both as <#60467#><#1277#>FUNCTION DEFINITION<#1277#><#60467#>s
and, using mathematical terminology in a loose way, say that the program
is <#60468#><#1278#>COMPOSED<#1278#><#60468#> of several functions. Because first one,
<#60469#><#1279#>area-of-ring<#1279#><#60469#>, is the function we really wish to use, we refer to
it as the <#60470#><#1280#>MAIN FUNCTION<#1280#><#60470#>; the second one, <#60471#><#1281#>area-of-disk<#1281#><#60471#>,
is an <#60472#><#1282#>AUXILIARY FUNCTION<#1282#><#60472#>.
The use of auxiliary functions makes the design process manageable and
renders programs readable. Compare the following two versions of
<#60473#><#1283#>area-of-ring<#1283#><#60473#>:
<#1290#>(d<#1290#><#1291#>efine<#1291#> <#1292#>(area-of-ring<#1292#> <#1293#>outer<#1293#> <#1294#>inner)<#1294#>
<#1295#>(-<#1295#> <#1296#>(area-of-disk<#1296#> <#1297#>outer)<#1297#>
<#1298#>(area-of-disk<#1298#> <#1299#>inner)))<#1299#>
<#1308#>(d<#1308#><#1309#>efine<#1309#> <#1310#>(area-of-ring<#1310#> <#1311#>outer<#1311#> <#1312#>inner)<#1312#>
<#1313#>(-<#1313#> <#1314#>(*<#1314#> <#1315#>3.14<#1315#> <#1316#>(*<#1316#> <#1317#>outer<#1317#> <#1318#>outer))<#1318#>
<#1319#>(*<#1319#> <#1320#>3.14<#1320#> <#1321#>(*<#1321#> <#1322#>inner<#1322#> <#1323#>inner))))<#1323#>
The definition on the left composes auxiliary functions. Designing it
helped us break up the original problem into smaller, more easily
solvable problems. Reading it reminds us of our reasoning that the area
is the difference between the area of the full disk and the area of the
hole. In contrast, the definition on the right requires a reader to
reconstruct the idea that the two subexpressions compute the area of two
disks. Furthermore, we would have had to produce the right definition in
one monolithic block, without benefit of dividing the problem solving
process into smaller steps.
For a small program such as <#60474#><#1328#>area-of-ring<#1328#><#60474#>, the differences between
the two styles are minor. For large programs, however, using auxiliary
functions is not an option but a necessity. That is, even if we are asked
to write a single program, we should consider breaking it up into several
small programs and <#60475#><#1329#>COMPOSING<#1329#><#60475#> them as needed. Although we are not
yet in a position to develop truly large programs, we can still get a
feeling for the idea by developing two versions in parallel.
The first subsection contrasts the two development styles with an example
from the business domain. It demonstrates how breaking up a program into
several function definitions can greatly increase our confidence in the
correctness of the overall program. The second subsection introduces the
concept of a variable definition, which is an additional important
ingredient for the development of programs. The last subsection proposes
some exercises.