1 / 17

Understanding Control in Programming: Expressions, Statements, and Evaluation Order

This chapter delves into the semantics of execution paths in programming languages, exploring expressions and their evaluation order. It discusses the nature of side effects, the importance of non-determinism, and the classifications of evaluation as strict or non-strict. The chapter also highlights the use of short-circuit evaluation in Boolean operations and contrasts different implementations of case and switch statements, including jump tables. Overall, it emphasizes the relationship between evaluation rules and side effects, illustrating their significance in programming languages.

trista
Télécharger la présentation

Understanding Control in Programming: Expressions, Statements, and Evaluation Order

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 7 - Control I: Expressions and Statements "Control" is the general study of the semantics of execution paths through code: what gets executed, when, and in what order. Louden, Programming Languages

  2. Expressions • 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. • If expressions could have arbitrary evaluation order, programs would become non-deterministic: any of a number of different outcomes might be possible. Louden, Programming Languages

  3. Side Effects • 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 intgetX() { 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! • Why? Louden, Programming Languages

  4. Strictness • An evaluation order for expressions is strict (eager) if all subexpressions of an expression are evaluated, whether or not they are needed to determine the value of the result, non-strict (lazy) otherwise. • Arithmetic is almost always strict. • Every language has at least a few non-strict expressions (?:, &&, ||). • A form of strict evaluation called applicative-order is common: "bottom-up" or "inside-out". Expressions are evaluated in the order they are encountered in evaluating the expression tree. Louden, Programming Languages

  5. Applicative Order Consider: (a+b)/(c+d)+((e-f)-g)/(h+j) – which operation is evaluated first? • Still leaves open whether left-to-right or not. Louden, Programming Languages

  6. Short Circuit Evaluation • Suppose Java did not use short-circuit evaluation • Problem: table look-up i= 1; while(i<=length)&&(LIST[i]!= value) i++; Louden, Programming Languages

  7. Short Circuit Evaluation • C, C++, and Java: use short-circuit evaluation for the usual Boolean operators (&& and ||), but also provide bitwise Boolean operators that are not short circuit (& and |) • Ada: programmer can specify either (short-circuit is specified with and then and or else) • Short-circuit evaluation exposes the potential problem of side effects in expressions e.g. (a > b) || (b++ / 3) Louden, Programming Languages

  8. Function calls • Obey evaluation rules like other expressions. • With side effects, order makes a difference. Louden, Programming Languages

  9. Case Statements • Rules • cases can be constants, constant expressions, constant ranges • no overlapping cases • error if unspecified case occurs (or may decide to do nothing if unspecfied case) • Implemented via jump table: vector stored sequentially in memory - each of whose components is an unconditional jump • Need one location in jump table for every value between range of possible values Louden, Programming Languages

  10. Switch Statements typedef enum {ADD, MULT, MINUS, DIV, MOD, BAD} op_type; char unparse_symbol(op_type op) { switch (op) { case ADD : return '+'; case MULT: return '*'; case MINUS: return '-'; case DIV: return '/'; case MOD: return '%'; case BAD: return '?'; } } • Implementation Options • Series of conditionals • Good if few cases • Slow if many • Jump Table • Lookup branch target • Avoids conditionals • Possible when cases are small integer constants • Flexible • Picks one based on case structure Louden, Programming Languages

  11. Targ0: Code Block 0 jtab: Targ0 Targ1 Targ2 Targ1: Code Block 1 • • • Targn-1 Targ2: Code Block 2 • • • Targn-1: Code Block n–1 Jump Table Structure Jump Targets Switch Form Jump Table switch(op) { case 0: Block 0 case 1: Block 1 • • • case n-1: Blockn–1 } Code Generated target = JTab[op]; goto *target; Louden, Programming Languages

  12. A jump table is an array of code addresses: • Tbl[ i ] is the address of the code to execute if the expression evaluates to i. • if the set of case labels have “holes”, the correspond jump table entries point to the default case. • Bounds checks: • Before indexing into a jump table, we must check that the expression value is within the proper bounds (if not, jump to the default case). • The check lower_bound  exp_value  upper bound can be implemented using a single unsigned comparison. Louden, Programming Languages

  13. Jump Table Space Costs • jump tables • best for large no. of case labels ( 8) • may take a large amount of space if the labels are not well-clustered. • A jump table with max. and min. case labels cmax and cmin needs cmax – cmin entries. This can be wasteful if the entries aren’t “dense enough”, e.g.: switch (x) { case 1: … case 1000: … case 1000000: … } • Define the density of a set of case labels as density = number of case labels/(cmax – cmin ) • Compilers will not generate a jump table if density below some threshold (typically, 0.5). Louden, Programming Languages

  14. Use of Switch Statements • if number of case labels is small ( ~ 8), use linear or binary search. • use number of case labels to decide between the two. • if density  threshold (~ 0.5) : • generate a jump table; else : • divide the set of case labels into sub-ranges such that each sub-range has density  threshold; • generate code to use binary search to choose amongst the sub-ranges; • handle each sub-range recursively. Louden, Programming Languages

  15. Guarded Commands Selection: if <boolean> -> <statement> []<boolean> -> <statement> ... [] <boolean> -> <statement> fi • Semantics: when this construct is reached, • Evaluate all boolean expressions • If more than one are true, choose one nondeterministically • If none are true, it is a runtime error Louden, Programming Languages

  16. Guarded Commands Idea: if the order of evaluation is not important, the program should not specify one In Haskell, first one that matches is used. Louden, Programming Languages

  17. Summary • 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. Louden, Programming Languages

More Related