Class 35: Conditionals and Loops

Held Wednesday, April 28

Summary

Contents

Handouts

Notes

• Are there final questions on exam 3?
  • Note that the only way to build ``integers'' with succ and pred is to start with zero.
  • An ``argument'' should be about a paragraph long and should take the form ``You should (should not) be able to assign XXX to YYY because ....'' I'd prefer if you'd also attempt to refute counter-arguments, but that is not strictly necessary.
  • Why are you making this simple grammar unambiguous? Because it's good practice. Also, we may derive meaning from the grammar. For example, if we were working with parenthesized expressions, we might treat concatenation as multiplication, and we might be working in a world in which order of multiplcation matters.

Control Structures

• Recall that there are three basic attribtues we want for control structures:
  • Locality: a statement should only have local effect
  • Limited entry: only a limited number of ways to enter the control structure
  • Limited exit: only a limited number of ways out of the control statement.

Blocks

• Blocks illustrate many of the principles.
• A block is a sequence of statements treated as a logical whole and typically surrounded by some key words (begin/end) or key symbols ({/}).
• Limited entry
  • In most languages, you must enter a block at the top.
  • This means that you cannot directly jump to any statement.
  • This means that we only need to consider the effect of local statements (those within a block) that precede a statement.
• Limited exit
  • While you may exit the block in multiple ways (e.g., doing all the statements or encountering a break), there is only one subsequent statement.
  • This makes it easier to keep track of what happens next, or what we need to happen within the block.

Conditionals

• A conditional is a form of control in which the statements executed are determined by one or more tests. Common conditionals include If Statements and Case Statements.
• In some sense, conditionals select which statements to execute.
• Conditionals are both useful and important as they allow programs to exhibit significantly different behavior (in terms of the statements executed) depending on the inputs.
• Languages without some form of selection have less power (formally and practically).
• While we have a general sense of the simplest conditionals (conditional branches and if statements), there are many design issues in other conditionals.
• A Case Statement consists of a case expression and a sequence of value/statement pairs. The expression is evaluated and used to select a particular value/statement pair.
• There are a number of interesting design decisions in case statements:
  • What are the possible types of values in the pairs?
  • Must those values form a continuous range?
  • Do we permit a "default" value?
  • What do the values "look like"? Must they be constants? Constant expressions? Can they be variables?
  • Can multiple value/statement pairs have the same value? If so, what is the meaning?

Guarded Conditionals

• An interesting variant of the conditional (and, in effect, the case statement) is Dijsktra's guarded conditional.
• It has the form

  if G1 -> S1
   | G2 -> S2
   | G3 -> S3
   ...
   | Gn -> Sn
  fi
  

• The G's are guards (boolean expressions that serve as tests).
• The S's are statements (stuff to execute).
• The meaning of a guarded conditional is:
  • If exactly one guard holds, the corresponding statement is executed.
  • If multiple guards hold, only one of the corresponding statements is executed. (The one to be executed is often unspecified.)
  • If no guard holds, the statement is erroneous.
• Why would we want such a statement?
  • To test mutually exclusive cases (as in a case statement).
  • Provide one form of nondeterminism in the language.
  • Prevent overspecification.
• What is overspecification? It is the programmer specifying (or being forced to specify) more than is absolutely necessary.
• Why is it a problem? Often, if the programmer specifies too much, it limits what the computer can do. For example, if either of two objects suffices for our purposes, we'd like to allow the computer to choose which one to use. Why? Perhaps one object is more efficient; perhaps one object would only be used in this place so the other could be thrown away.
• Consider a typical maximum function

  Object max(Comparator compare, Object x, Object y)
  {  
    if (compare.lessThan(x,y))
      return y;
    else
      return x;
  } // max
  

• Here, we're saying that we use y as the maximum, even when they're equal. In most cases, we don't really care which we use.
• Using guarded conditionals, we might write

  Object max(Comparator compare, Object x, Object y)
  {  
    if compare.lessThan(x,y) -> return y;
     | compare.lessThan(y,x) -> return x;
    fi
  } // max
  

• Guarded conditionals might also be useful for event-oriented programming.

    if mouseIsDown -> handleMouse()
     | keyIsDown -> handleKey()
    fi
  

• If we were to include guarded conditionals in our language, we would have to consider a number of issues.
  • Should the implementation be required to be nondeterministic? Why or why not?
  • Should the implementation be required to execute all the guards? Why or why not?
  • In what order should the guards be executed?
  • Can guards have side-effects?
  • Should we permit a default (other than with ``true'')?

History

• Created Tuesday, January 19, 1999 as a blank outline.
• Filled in the details on Wednesday, April 28, 1999. Many details were based on outline 16 and outline 17 of CS302 98S.
• Removed uncovered material (all on loops) on Sunday, May 2, 1999.