Feldman/Koffman, 3e Chapter 5

Instructor's Manual for

Questions and comments to mfeldman@seas.gwu.edu

Chapter 5 Decision Statements; Writing Simple Functions and Packages

last revised April 1999

Chapter Objectives

The student will

be introduced to Boolean expressions and the IF statement in its various forms
be introduced to decision steps in algorithms
learn how to desk-check or trace an algorithm
learn how to write simple functions
learn how to write a simple package that provides some functions

New Terms

Section 5.1

alternative steps	conditions
Boolean expression	relational operators
`True`	`IF` statement
`False`

Section 5.2

decision step

pseudocode

Section 5.3

desk-check

trace

Section 5.4

extending a problem solution

solution by analogy

Section 5.5

multiple-alternative decision	nested `IF` statements
decision table

Section 5.7

function specification

function body

Notes and Suggestions

General Suggestions

This chapter introduces the standard decision (IF) control structures, but also the writing of simple system structures in the form of packages exporting simple functions. Following on the philosophy set out in the notes for Chapter 4, I maintain that students should learn that the main use of subprograms is to support reuse, and therefore that functions are best written to be generally usable, then placed in packages grouping similar functions. This early commitment to encapsulation of related functions in a single package builds the foundation for more advanced material in abstract data types and object-oriented programming.

Section 5.1

Discuss the yesterday/today/tomorrow case study with your students. Emphasize that while enumeration types are very useful, they do not wrap around. I use this as an example of how programming languages don't always provide a perfect mapping to real-world ones, and therefore we have to "code around" these imperfections.

Also in this case study, discuss the advantages of using attributes like 'First and 'Last instead of "magic numbers" (explicit constant values) like Monday and Saturday. In this case study, we might want to "localize" the program by changing the names of the days to those of (for example) German. This could be done by changing exactly one statement, because we used attributes throughout the program. This is a good example of "designing for the future".

Not all students understand easily the difference between single- and two-alternative IF statements. Emphasize that in the latter, only one of the alternatives is executed and control then passes to the statement following the END IF.

Students with experience in other languages may be surprised that "not equal" is represented in Ada by the symbol /=. Those with Pascal experience are in for a rude awakening if they write <> instead, because <> is a valid symbol in Ada and the compiler will signal this with a "symbol out of context" message of some sort.

Perhaps someday language designers will reach agreement on a common symbol for "not equal."

You might point out as well that "greater than or equal" is written >=; the symbol => is usually called "arrow" in Ada circles, and is used for other purposes, such as associating the name of a parameter with its value. Writing => where >= is meant will lead to a "symbol out of context" message from the compiler.

Section 5.3

Encourage students to practice desk-checking sooner rather than later. This is a skill that is richly rewarded. You might call it "playing computer," in which students pretend that they can only follow, line by line, the instructions of the algorithm or program, and cannot think independently.

Section 5.4

Referring to the simple payroll example in this section, emphasize again the advantage of using constants instead of "magic numbers" embedded in a program.

Building on work that has already been done, instead of "re-inventing the wheel," is an admirable approach. You might wish to emphasize that, while adapting one's own work or the programs in the book is encouraged, the line must be drawn at copying programs written by classmates (unless you specifically authorize it)! The class environment imposes limits on reuse not usually present in industry! You might find it helpful to distribute or adapt my course guide on collaboration, which I adapted from one developed by my colleague Dianne Martin. If you have similar material you'd like to contribute to this website, please let me know.

Section 5.5

Students with Pascal experience may need a bit of help in understanding Ada's "fully-bracketed" control structures, especially the ELSIF and END IF reserved words. Point out the difference between ELSIF, which adds an alternative to an IF, and ELSE IF, which nests an entire IF structure inside another.

The "dangling ELSE" problem so familiar to Pascal and C programmers does not occur in Ada because of this bracketing. Point out that there is no syntactic difference between a one-statement sequence in an IF, and a multi-statement sequence. BEGIN and END (or {} as in C) are not used in Ada to distinguish these.

Have your students practice translating decision tables into IF statements, making sure to get the order of conditions correct.

Section 5.6

Ada 95 provides a number of standard libraries, one of which is a generic elementary functions library, Ada.Numerics.Elementary_Functions. The math libraries are used in various places in the book.

Students witth Fortran or Pascal backgrounds might be surprised that these basic math functions are in a package and not "intrinsic" to the language, but this is definitely Ada's style. Students with C experience will recognize this as a rough equivalent to math.h.

Section 5.7

Parameters in an Ada function cannot be modified, even locally, within the function body. This will probably come as an unpleasant surprise to students with Pascal experience. Explain that a local variable can always be declared to hold a copy of the parameter, if it must be changed.

This is a good opportunity to open the discussion of local variables, which are created when the function is called and destroyed just before the function returns to its caller. Emphasize that a function must have a RETURN statement that returns a value of the proper type.

Our examples show function specifications and function bodies. The specification is usually optional; we include it in early examples to prepare the student for writing packages, in which a function specification appears in the package specification.

Section 5.8

Here is another package whose specification and body students can examine. Reiterate the role of the package specification as a "contract with the user." Explain that when a function is defined in a package the name, type, and order of parameters must be identical in the specification and the body. Emphasize that the main purpose of a package is to collect related operations in a reusable component.

It is useful to demonstrate to students how a client of a package can be compiled if that package's specification exists; the package body need not exist. This emphasizes the "contract" idea--both the body and the client must be consistent with the spec.

I have found that students who know C or Turbo Pascal have expectations that are somewhat different from Ada's package structure. In Turbo Pascal, the interface (spec) and implementation (body) are placed in the same file; a C "header file" is usually copied in and compiled "on the fly". Also, students of C might think that an Ada file creates visibility, in the sense that everything "lower" in a file "sees" that which is defined "higher" in the file. This is not true in Ada, in which the source file is a rather unimportant concept. The important concept is the compilation unit, which for our purposes is a package spec, package body, or main program.