Types and Programming Languages Lecture 2 Simon Gay Department of Computing Science University of Glasgow 2006/07

Simple Expression Language To introduce the main ideas of the course, we will begin by looking at a simple language of expressions. Abstract syntax of expressions e is defined by this grammar: e ::= integer literal | true | false | e + e | e == e | e & e | if e then e else e Abstract expressions should be understood as trees and we use brackets to make this clear. (1+2)+3 + + 3 1 2 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Types and Programming Languages Lecture 2 - Simon Gay We are going to define the meaning of expressions by specifying how to evaluate them, giving the expected results: e.g. (if 1==2 then 3 else 4)+1 evaluates to 5 . The language contains many nonsensical expressions such as (2==3)+4 which we will eliminate by means of a type system. It’s useful to separate out the integer and boolean literals: we call them values, v. The grammar becomes v ::= integer literal | true | false e ::= v | e + e | e == e | e & e | if e then e else e Sometimes we will refer to expressions as terms. 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Operational semantics of expressions We define the semantics (meaning) of expressions by formalizing step-by-step calculation. e  e’ means that e is transformed into e’ by one step of calculation or evaluation. We say that e reduces to e’.  is called the reduction relation. We write e * e’ if e is transformed into e’ by some number of reduction steps (possibly zero). Examples: 1+(2+3) * 6 if 2==4 then 1 else 3 * 3 if we define  in a suitable way. This approach is called operational semantics. 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Operational semantics of expressions We want + to represent addition. For values: 0 + 1  1 1 + 1  2 and so on… In general: u + v  w if u and v are integer literals and w is their sum 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Operational semantics of expressions Similarly we want == to represent the equality test: u == v  true if u and v are the same integer literal u == v  false if u and v are different integer literals We want & to represent logical conjunction: u & v  w if u and v are boolean literals and w is their logical conjunction 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Operational semantics of expressions Conditional expressions are similar when the condition is a value: if true then e else e’  e if false then e else e’  e’ Notice that in these cases we are not necessarily reducing directly to a value - in general further steps are required. Example: if true then 1+2 else 4  1+2  3 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Operational semantics of expressions Exercise: Give some examples of expressions for which we have not yet specified reductions. Two categories: 1. Expressions which we do not intend to have a value e.g. 1+true if 3 then 4 else 5 2 & 3 We will not define reductions - these expressions are stuck. (Alternative: 1+true  error where error is a new expression.) 2. Sensible expressions which are more complex e.g. 1+(2+3) if 3==4 then 5 else 6 (1==2)&(3==4) We need to deal with these… 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Operational semantics of expressions We define rules allowing part of an expression to be reduced, maintaining the overall structure. Addition: to reduce e+f when e is not a value, first reduce e by one step, giving e’, then we have e’+f. more concisely: if e  e’ then e+f  e’+f notation: general: IF we know that the reduction above the line is possible THEN we conclude that the reduction below the line is possible 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Operational semantics of expressions Exercise: can we reduce 1+(2+3) ? If so, what do we get? Our rule does not apply to 1+(2+3) because 1 is already a value and has no reductions. In general, applying the rule repeatedly leads to an expression of the form v+e so we need a new rule for expressions of this form. Exercise: what should the rule be? Exercise: how does (1+2)+(2+3) reduce? (1+2)+(2+3)  3+(2+3)  3+5  8 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Operational semantics of expressions The rules for + specify an evaluation order: evaluate the left operand first. For + this is not very important, but for conditionals it is: Exercise: how does if 1==2 then 3+4 else 1+2 reduce? if 1==2 then 3+4 else 1+2  if false then 3+4 else 1+2  1+2  3 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Operational semantics of expressions Exercise: what are the rest of the reduction rules for == ? Similarly we can complete the rules for & : Alternatively we can define shortcut evaluation: and then we no longer need the u & v  w rule. 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Summary: operational semantics of expressions u + v  w (R-SumLit) if u and v are integer literals and w is their sum (R-SumL) (R-SumR) u & v  w (R-AndLit) if u and v are boolean literals and w is their conjunction (R-AndL) (R-AndR) 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Summary: operational semantics of expressions u == v  true (R-EqT) if u and v are the same int. lit. u == v  false (R-EqF) if u and v are different int. lits. (R-EqL) (R-EqR) (R-IfT) (R-IfF) (R-IfC) Structural Operational Semantics: due to Gordon Plotkin. 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Summary: operational semantics of expressions The meaning of an expression e is calculated by reducing it: until a stuck expression is reached. Reductions are only possible if they can be derived from the rules. A stuck expression is either a value (representing the meaning of the original expression) or a non-value which cannot be reduced any further (representing a run-time error). 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Types and Programming Languages Lecture 2 - Simon Gay Deriving reductions Formally the existence of each reduction is justified by a derivation using the reduction rules. For example, the reduction if 1==2 then 3+4 else 1+2  if false then 3+4 else 1+2 is justified by 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Types and Programming Languages Lecture 2 - Simon Gay What have we defined? Let Expr be the set of all expressions. We have defined a relation R on Expr: a subset of Expr  Expr. When (e,f)  R we write e  f . R is the smallest relation which is closed under the rules. That’s what we mean by saying that reductions are only those specified by the rules. This is called an inductive definition. The rules are called inference rules. A rule with no hypothesis (e.g. u == v  true) is called an axiom. 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Avoiding run-time errors We will say that e  Expr is valid if whenever it reduces to a stuck expression s, s is a value. Let Valid be the set of all valid expressions: Valid  Expr. In fact, Valid  Expr. (If Valid = Expr: no problem!) The Simple Expression Language is so simple that given e  Expr we can work out whether or not e  Valid simply by reducing e until we get stuck (which is bound to happen) and then examining the stuck expression. Exercise: why doesn’t this work in real programming languages? 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Avoiding run-time errors We would like to define a set of safe expressions, Safe  Expr, such that given an expression e we can work out whether or not e  Safe without reducing e Safe  Valid, so that if e  Safe then e is valid (has no run-time errors) we expect that Safe  Valid but we want to make sure that the gap between Safe and Valid is not too large: if we adopt the principle of rejecting unsafe expressions, then we don’t want to reject too many valid expressions by mistake. The idea is to define a type system, and then Safe will be the set of expressions that are accepted by the typechecker. 2006/07 Types and Programming Languages Lecture 2 - Simon Gay

Types and Programming Languages Lecture 2 - Simon Gay Reading Pierce: 3.1, 3.2, 3.4, 3.5 Exercises Pierce: 3.5.10, 3.5.18 Exercise sheet 1 2006/07 Types and Programming Languages Lecture 2 - Simon Gay