Exam Delay Exam II will be held during the first fifty (50) minutes of class on 13 November 2003.

Control 1: Expressions and Statements Purist view: – An expression yields (or produces) a new value and causes no other side-effect. –A statement yields no value and is executed specifically because of some side-effect that it produces. –These distinctions are blurred in many languages nowadays (C, Java, Perl, Ruby,...) in which expressions can have side effects, and can be treated as statements. In fact, in such languages, statements are often treated as a special case of expressions yielding null or void values.

Expressions Expressions are typically defined recursively to be: 1.primitive operands (such as literals and variable references) 2.operations or functions applied to expression arguments Operations are usually written using infix notation, but different languages have supported both prefix (lisp) and postfix (Forth) notation. Function call is expressed using prefix notation in most languages, but some languages use postfix. Language built-in operations are typically inserted into a precedence hierarchy and associativity (left or right). Nowadays the distinction between built-in operations and functions are somewhat blurred. In days gone by, compilers would almost always generate inline code for operations, but subprogram calls for functions.

Applicative vs. Normal Order Evaluation Applicative order evaluation is the typical order used in implementing programming languages. (Some refer to this as programming language order.) It requires that each operand be evaluated before its operator is applied. Although Louden refers to this as strict evaluation, his use of the term is somewhat loose. Strict evaluation refers to bottom- preserving evaluation of operations on a lattice (or complete partial order). This essentially means that if one component of an expression is undefined, the result of the expression will be undefined. Normal order evaluation is less common and is typically seen in functional languages. In normal order evaluation, no operation is evaluated unless its value is required in order to construct the result value for an expression. In fact, most languages mix the two orders. Think of && and || of C as well as and then and or else of Ada as being instances of normal order creeping into an otherwise applicative order language. In typical programming languages, control structures such as if-then- else introduce applicative rather than normal order evaluation.

Dijkstra’s Guarded if Extremely general and powerful construct: if B1 -> S1 | B2 -> S2... | Bn -> Sn fi If one of the guards Bi is true, execute Si. Otherwise, yield an error. If more than one guard is true, choose the one to execute nondeterministically. It is not specified whether or not all guards are to be evaluated.

If statements If appears in many closely related forms in various programming languages. It can be viewed as the following restriction on the guarded if: if B -> S1 | ~B -> S2 fi Dangling else problem. How is it solved? –bracketing keyword –most closely nested if Too many elses problem: –Add keyword elseif

Case/Switch Like guarded command of following sort: if x = v1 -> S1 | x = v2 -> S2... | x = vn -> Sn Problems: –C: fall-through to next case (avoided with break ) –C: labels are just labels. Misspelling default causes pain and suffering.