Chapter 7 Topics Introduction Introduction Arithmetic Expressions Arithmetic Expressions: Design Issues

Chapter 7 Topics Introduction Introduction Arithmetic Expressions Arithmetic Expressions: Design Issues

Topics Chapter 7 • Introduction • Arithmetic Expressions • Infix, Prefix and Postfix • Overloaded Operators Expressions and • Type Conversions Assignment Statements • Relational and Boolean Expressions • Short-Circuit Evaluation • Assignment Statements • Mixed-Mode Assignment Introduction Introduction • Expressions are the fundamental means of specifying • Other issues are type mismatches, coercions computations in a programming language and short-circuit evaluation – In imperative languages expressions are the right hand side of assignment statements • The essence of imperative languages is the – In functional languages computation is simply expression dominant role of assignment statements that evaluation change the values of memory cells • To understand expression evaluation, we need to be familiar with the orders of operator and operand evaluation – May be only partially specified by associativity and precedence rules – If not completely specified we might get different results in different implementations Arithmetic Expressions Arithmetic Expressions: Design Issues • Arithmetic evaluation was one of the • Design issues for arithmetic expressions motivations for the development of the first – Operator precedence rules? programming languages – Operator associativity rules? • Arithmetic expressions consist of operators, – Order of operand evaluation? operands, parentheses, and function calls – Operand evaluation side effects? – Operator overloading? – Type mixing in expressions? 1 Operator Arity Operator Precedence Rules • A unary operator has one operand • The operator precedence rules for expression • A binary operator has two operands evaluation define the order in which adjacent operators of different precedence levels are • A ternary operator has three operands evaluated • Typical precedence levels – parentheses – unary operators – ** (if the language supports it) – *, / – +, - – Relational Operators Comparison of Precedence Associativity Operator C-like Ada Fortran • The operator associativity rules for expression Unary - 7 3 3 evaluation define the order in which adjacent ** n/a 5 5 operators with the same precedence level are * / 6 4 4 evaluated + - 5 3 3 == != 4 2 2 • Typical associativity rules < <= ... 3 2 2 – Left to right, except **, which is right to left not 7 2 2 – Sometimes unary operators associate right to left (e.g., in FORTRAN) • APL is different; all operators have equal precedence and all operators associate right to left • Smalltalk: binary methods that we see as operators have equal precedence and left associativity • Precedence and associativity rules can be overriden with parentheses Associativity of Operators Associativity Lang + - * / Unary - ** == != < ... • For +,* operators that have the associative C-like L R n/a L property optimizing compilers may reorder Ada L non non non expression evaluation Fortran L R R L – In theory x * y * z * w can be evaluated in any order VB L R L non – But if x and z are very large and y and w are very small we can get a different results from • Note that left associative relational operators ((x * y) * z) * w ((x * z) * y) * w allow expressions such as a < b < c – In floating point arithmetic we can lose precision or – But in C this means even produce infinities • if (a < b) then (1 < c) else (0 < c) – Not – In integer arithmetic we have overflow or • (a < b) && (b < c) wraparound • With non-associative relational operators – We could specify order of evaluation with expression such as a < b < c are not legal parentheses (x * y) * (z * w) 2 Ruby and Smalltalk Expressions Ternary Conditional Operator • All arithmetic, relational, and assignment • Conditional Expressions operators, as well as array indexing, shifts, and – In most C-like languages (C, C++, Java, PHP, bit-wise logic operators, are implemented as Javascript, …) methods average = (count == 0) ? 0 : sum / count - One result of this is that these operators can all Same as this code: be overridden by application programs if (count == 0) average = 0 else average = sum /count Some languages do not require parentheses: average = count == 0 ? 0 : sum / count Operand Evaluation Order Side Effects • Operand evaluation order • Side effects occur when: 1. Variables: fetch the value from memory – A function changes one of its parameters 2. Constants: sometimes a fetch from memory; – A function changes a non-local variable sometimes the constant is in the machine language – A function performs input or output instruction • Example 3. Parenthesized expressions: evaluate all operands and operators first a = 10; /* assume that fun changes its parameter */ • Evaluation order is generally irrelevant except b = a + fun(&a); when an operand is a function call that has side effects Side Effects Functional Side Effects • Changing a non-local variable • Two possible solutions to the problem 1. Write the language definition to disallow functional side int a = 5; effects int func(x){ • No two-way parameters in functions a = 42; • No non-local references in functions return x % a; • Advantage: it works! } • Disadvantage: inflexibility of one-way parameters and lack void main(){ of non-local references a = a + func(84); 2. Write the language definition to demand that operand } evaluation order be fixed • Disadvantage: limits some compiler optimizations • Is the value of a 7 or 44? • Java requires that operands appear to be evaluated in left- to-right order • C and C++ do not require any fixed order 3 Side Effects Referential Transparency • The generally accepted rule for programming is • An expression has referential transparency if it that value returning functions should not have can be replaced with its value without side-effects changing the action of the program • Less generally accepted is the notion that ans1 = (fun(a)+b) / (fun(a)+c); procedures should not have side effects except Temp = fun(a) by modifying one or more arguments ans2 = (temp+b) / (temp+c); • But most imperative and OO languages have no • Absence of functional side effects is neccesary mechanisms to enforce side-effect rules (but not sufficient) for referential transparency • We will discuss further with functional languages Infix Expression Semantics Prefix and Postfix notations • Most programming languages use infix notation • Two different ways to represent expressions; • Infix is inherently ambiguous unless both are unambiguous associativity and precedence are defined – Infix (a + b) - (c * d) • Ex a + b – c * d usually means (a + b) – (c * d) – Polish Prefix: - + a b * c d • In Smalltalk it means ((a + b) – c) * d – Polish Postfix: a b + c d * - • Also know as Reverse Polish Notation or RPN • In APL it means a + (b – (c * d)) • Introduced early 20th century by Polish mathematician Jan Lukasiewicz – Cambridge Polish: (- (+ a b) (* c d)) • Infix uses associativity and precedence to disambiguate. Obtaining Prefix and Postfix Forms Evaluation of RPN Expressions • Both forms can be obtained by traversing • Uses a stack: expression trees 1. Get next token (operator or operand) from input stream – Prefix walk or preorder traversal 2. If the token is an operand 1. Generate the value of the node 2. Visit the left subtree push it on the stack 3. Visit the right subtree else // an n-ary operator – Postfix walk or postorder traversal pop the top n operands from the stack (R to L) 1. Visit the left subtree perform the operation 2. Visit the right subtree push result on top of the stack 3. Generate the value of the node 3. Repeat 1-2 until EOF 4. Pop final result off the stack 4 RPN Example Example 2 Input: 2 3 * 12 3 / + 5 3 * 6 - + Input: 3 4 5 * - (Infix 3 – 4 * 5) TokenAction Stack 2 Push (2) - 3 Push (2 3) Token Action Stack * Pop 3, Pop 2; 3 Push (3) 3 * Push 2 * 3 = 6 (6) 12 Push (6 12) 4 Push (3 4) 3 Push (6 12 3) 4 5 5 Push (3 4 5) / Pop 3, Pop 12; Push 12/3 = 4 (6 4) * Pop 5, Pop 4; + Pop 4, Pop 6 Push 4*5 = 20 (3 20) Push 6+4 = 10 (10) 5 Push (10 5) - Pop 20, Pop 3 3 Push (10 5 3) Push 3–20 = -17 (-17) * Pop 3, Pop 5; EOF Pop and return -17 Push 5*3 = 15 (10 15) 6 Push (10 15 6) - Pop 6, Pop 15 Push 15-6 = 9 (10 9) + Pop 9, Pop 10 Push 10+9 = 19 (19) EOF Pop and return 19 Unary Operators Overloaded Operators • Using Polish notation it is not possible to have • Use of an operator for more than one purpose the same operator for both unary and binary is called operator overloading operations – e.g. the binary and unary minus • Some are common (e.g., + for int and float) • Two solutions: • Some are potential trouble (e.g., * in C and – Use Cambridge Polish (parenthesized) C++) – Use a different symbol (e.g, ~) – Loss of compiler error detection (omission of an • With Cambridge Polish notation, operators operand should be a detectable error) such as + and – can be used as n-ary operators – Some loss of readability (+ a b c d) is a + b + c + d • C++, C#, Ada allow user-defined overloaded operators Overloaded Operators Type Conversions • A design mistake in Javascript: using + for • A narrowing conversion is one that converts an addition as well as string concatenation object to a type that cannot include all of the var x = “10” values of the original type e.g., float to int var y = x + 5; // y is 105 • A widening conversion is one in which an Var z = x – 3; // z is 7 object is converted to a type that can include at least approximations to all of the values of the original type e.g., int to float • Note that widening conversion can lose precision, but the magnitude is retained 5 Type Conversions: Mixed Mode Explicit Type Conversions • A mixed-mode expression

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    8 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us