P ROGRAMMING L ANGUAGES : C ONTROL 1

S LIDES R EFERENCES Kenneth C. Louden, Control I: Expressions and Statements: Principles and Practice. 2

I NTRODUCTION "Control" is the general study of the semantics of execution paths through code: what gets executed, when, and in what order. Most important control issue in modern languages: procedure/function/method call and return, studied in Chapter 10. Here we study more localized control issues in expressions and statements, and: Exception handling, which involves non-local control but has a local component too. 3

E XPRESSIONS In their purest form, expressions do not involve control issues: subexpressions can be evaluated in arbitrary order, and the order does not affect the result. Functional programming tries to achieve this goal for whole programs. A few expressions that can modify the execution/evaluation process: if-then-else expressions, short-circuit boolean operators, case/switch expressions. If these could have arbitrary evaluation order, programs would become non-deterministic: any of a number of different outcomes might be possible. Usually this is not desirable. 4

S IDE E FFECTS A side effect is any observable change to memory, input or output. A program without any side effect is useless. Side effects expose evaluation order: class Order { static int x = 1; public static int getX() { return x++; } public static void main(String[] args) { System.out.println( x+getX() ); } } This prints 2, but the corresponding C program will usually print 3! Referential transparency limits side effects. 5

S TRICTNESS An evaluation order for expressions is strict if all subexpressions of an expression are evaluated, whether or not they are needed to determine the value of the result, non-strict otherwise. Arithmetic is almost always strict. Every language has at least a few non-strict expressions (?:, &&, || in Java, C, C#). Some languages use a form of non-strictness called normal-order evaluation: no expression is ever evaluated until it is needed (Haskell). Also called delayed evaluation. 6

F UNCTION CALLS Obey evaluation rules like other expressions. Applicative order: evaluate all arguments (usually left to right), then call the procedure. Normal order: pass in unevaluated representations of the arguments. Only evaluate when needed. With side effects, order makes a difference. Representation of argument value also makes a difference (value or reference?). 7

E XAMPLES C and Scheme: no explicit order required for subexpressions or arguments to calls. Java always says left to right, but warns against using that knowledge. Case/switch/cond expressions imply a top-down order: (define (f) (cond (#t 1) (#t 2))) Theoretically, this could return either 1 or 2 (non- determinism—the "guarded if" of text). Java and C outlaw this: no duplicate cases. 8

S EQUENCING AND S TATEMENTS A sequence of expressions makes no sense without side effects. So, a referentially transparent program should not need sequences. Both ML and Scheme have sequences: (e1;e2;…) [ML] and (begin e1 e2 …) [Scheme]. 9

S TATEMENTS Can be viewed as expressions with no value. Java, C have very few: if, while, do, for, switch Scheme: valueless expressions also exist: define, set! (some versions give these values). Declarations may be neither expressions nor statements. 10

S UMMARY 1 Every language has three major program components: expressions, statements, and declarations. Expressions are executed for their values (but may have side effects), and may or may not be sequenced. Statements are executed solely for their side effects, and they must be sequenced. Declarations define names; they can also give values to those names. They may or may not be viewed by a language as expressions or statements. 11