Class 34: Control

Held Monday, April 26

Summary

• Topics for and outlines of presentations due.

Contents

Notes

• Any questions on exam 3? Here are some that I've received.
  • What form should the Result in the add predicate take? It should be a number using the pred/succ notation.
  • What happens when you concatenate a string with the empty string? For example, are ``(empty)empty'' and ``empty(empty)'' different? When you concatenate a string with the empty string, you get the string back. Hence, both of those are the same string, which is really ``()''.
  • Where are pred and succ defined? They're not; they're just placeholders.
• I've updated two questions to make them somewhat easier (I removed two cases in the record equality question and allowed you to drop one of the grammars).

Defining New ``Sets'' of Values

• In our discussion of types, we noted that it is often useful to define a new type as a set of values.
• In our discussion of object-oriented programming, we noted that it is often useful to think of OOP as a natural way of dealing with types.
• Is there a way to combine the ideas? Can we use OOP techniques to define new sets of values?
• Not so surprisingly, the answer is yes.
• We'll use inheritance/subclassing as a technique. The superclass will serve as the ``set'', the subclasses as the values.
  • No, it's not completely elegant, but it suffices for many things.
• For example, in Java we might define a DayOfWeek type as:

  public class DayOfWeek { };
  public class Monday extends DayOfWeek { };
  public class Tuesday extends DayOfWeek { };
  public class Wednesday extends DayOfWeek { };
  public class Thursday extends DayOfWeek { };
  public class Friday extends DayOfWeek { };
  public class Saturday extends DayOfWeek { };
  public class Sunday extends DayOfWeek { };
  

• Here's how we might create a new variable set to Monday.

    DayOfWeek today = new Monday();
  

• Here's how we might write a weekend predicate

  public boolean weekend(DayOfWeek day) {
    return (day instanceOf Saturday) ||
           (day instanceOf Sunday);
  }
  

• Another technique (not restricted to object-oriented languages) is to use numeric constants to define the various values. We can make them more type-like in an OOP language.

  public class DayOfWeek {
    // Numeric equivalents to the days.  Should only be used in
    // the constructor.
    public static int SUNDAY = 0;
    public static int MONDAY = 1;
    public static int TUESDAY = 2;
    public static int WEDNESDAY = 3;
    public static int THURSDAY = 4;
    public static int FRIDAY = 5;
    public static int SATURDAY = 6;
  
    // The day for the current day of the week.
    protected int day;
  
    // Build a new day of the week.
    public DayOfWeek(int day) { this.day = day; }
      
    // Compare two days of the week
    public equals(DayOfWeek other) {
      return this.day == other.day;
    }
  
    // Advance to the next day.
    this.day = (this.day + 1) % 7;
  } // class DayOfWeek
  

Control Structures

• Every language needs a way to sequence the basic operations, if only to ensure that there is a way to translate to assembly code (which is clearly sequenced).
  • Sometimes this sequencing will be explicit (e.g., in many languages, statements listed in sequence will be executed in sequence).
  • Sometimes the sequencing will be implicit (e.g., in 3 + 4 * 5, in Prolog, or in some functional languages).
• A key feature of most imperative languages is that they provide a variety of explicit control structures.
• What are the key control structures? At the most primitive level, there are only three:
  • Sequencing: Except when other control structures apply, statements are executed in sequence.
  • Unconditional branch: Specifies the next statement to be executed (often not the one directly after the current statement).
  • Conditional branch: Specifies a test to execute and a next statement to be used if the test succeeds.
• We might want to consider control in regards to program analysis.
  • Successful analysis of an individual statement often requires a clear understanding of what can/must be true before that statement is executed.
  • This allows us to gain a better understanding of what is true after the statement is executed.
• For example, if we know that y is 2, then after x = 3*y we know that x is 6.
• Similarly, after executing

  if (x < 2)
    y = 2;
  else
    y = x;
  

  we know that y has a value (and that that value is at least 2).
• As we've just noted, unrestricted branches make it difficult to determine what holds before a statement, since we don't know what led to the statement (and because the control that leads to that statement can be scattered throughout the program).
• Hence, language designers include high-level control structures that abstract away from the underlying implementation.
• What do we want from our control structures?
  • Locality. One can only reach statements through some local action.
  • Restricted environment. The ability to restrict the effect of the rest of the program on statements within the structure.
  • Limited entry. (Related to the two previous concepts.) There are only a limited number of ways we can enter a control structure or statement.
  • Limited exit. There are only a limited number of ways we can exit the control structure, and only a limited number of subsequent statements. (Hopefully, ``limited'' == ``one''.)
• What are some of the more popular high-level control structures?
  • Blocks (tie together a number of statements for sequencing and to define a local area).
  • Conditionals (decide between choices).
  • Loops (do things repeatedly)
  • Procedure/function calls (parameterized blocks)
  • Exceptions (alternate control for errors and uncommon occurrences)
  • Iterators (repetition with data structures)

History

• Created Tuesday, January 19, 1999 as a blank outline.
• Filled in the details on Monday, April 26, 1999. Many details were based on outline 16 of CS302 98S.
• Removed uncovered material on Wednesday, April 28, 1999.