Concepts of programming languages

Concepts of programming languages Lecture 5 Wouter Swierstra 1

Announcements Submit your project proposal to me by email on Friday; The presentation schedule in now online Exercise session after the lecture. 2

Last time Study an example domain specific language (SVG). What different approaches are their to implementing domain specific languages? 3

This time How can we define the semantics of trivial languages? What is the λ-calculus and what is its semantics? 4

Micro programming languages Previously, we studied SVG a realistic, but limited language. The drawback is that our semantics is cluttered by many other language design choices. For now, let s focus on smaller languages 5

A simple language e ::= True False if e then e else e We would like to define a dynamic semantics by defining an inductive relation e e, to denote that the expression e can take a single reduction step to a new expression e. Question: What are the values of this language? Question: How should this relation be defined? 6

Dynamic semantics if True then e else e e E-True if False then e else e e E-False c c if c then e else e if c then e else e E-If The first two rules are fairly obvious 7

Dynamic semantics if True then e else e e E-True if False then e else e e E-False c c if c then e else e if c then e else e E-If The first two rules are fairly obvious Question: Why are there no rules for True and False? Question: Why do we need the last rule? 7

Stuck terms A good semantics should ensure that each term: is either a value; or can make a reduction step. If this property does not hold it usually indicates that there are rules missing. As a result there are stuck terms that we cannot evaluate further, even if they are not yet values. 8

Funny rules Question: What happens if we add the following rule: e e if c then e else e if c then e else e 9

Funny rules Question: What happens if we add the following rule: e e if c then e else e if c then e else e We have more than one way to evaluate certain expressions we have too many rules. 9

Uniqueness of derivations A good semantics should also ensure that there is only one way to evaluate any expression. In this language, this is not too important we will always end up with the same value even if there is more than one derivation. But if multiple derivations exist, we cannot accurately predict how long it will take to evaluate an expression (or the order that certain effects may be triggered, when a program crashes, etc.) 10

Unicity of reduction steps Lemma If e e and e e then e = e. The proof is by rule induction on the derivations. Intuitively, we only have one possible rule to apply to a term. 11

Multiple steps Although this defines a single reduction step, how can we evaluate: if (if True then False else False) then True else True This requires more than one step! 12

Multiple steps Although this defines a single reduction step, how can we evaluate: if (if True then False else False) then True else True This requires more than one step! For that reason, we typically consider the relation e e consisting of zero or more reduction steps: e e 12 e e e e e e

Further extensions e ::= True False if e then e else e zero the number 0 succ e add one to a number iszero e check if a number is 0 Question: What new rules do we need to add to our semantics? 13

New rules e e succ e succ e e e iszero e iszero e iszero zero True iszero (succ nv) False To ensure the second and fourth rule don t overlap, we have the convention that nv refers to a numeric value, built only of only zero and succ. Question: Are there any stuck terms now? 14

Types By introducing a static semantics we can rule out such invalid this fixes our dynamic semantics. Alternatively, we could introduce an explicit error state that throws a dynamic exception when a run-time type error is encountered. But let s try to rule out these illegal expressions using types. 15

Types t ::= Bool Nat There are two types booleans and natural numbers. Next, let s try to define a relation e : t when the expression e has type t. Question: What rules should we add? 16

Static semantics True : Bool zero : Nat False : Bool e : Nat succ e : Nat e : Nat iszero e : Bool c : Bool e : t e : t if c then e else e : t 17

Soundness At this point, we typically aim to show type soundness every well-typed term is a value or can be reduced further (progress). if a well-typed term e : t can take a next step e e, then e : t (preservation) Together, these two properties guarantee that a well-typed term will never get stuck, but instead can be evaluated to a value. To do so, we typically use rule induction over our static and dynamic semantics. 18

Exercise Suppose we want to add a new construct to our language that represents addition: add e e Question: What new rules do we need to add to our static and dynamic semantics? Do progress and preservation still hold? 19

Solution Many possible choices exist. One possible choice is: e : Nat e : Nat add e e : Nat add v v (v + v ) e e e 1 e1 add v e add v e add e 1 e 2 add e1 e 2 But we could also evaluate in a different order, interpret booleans as 0 and 1, 20

More features At this point, we could define yet more features, but our language is growing rapidly as is the number of rules that we need to define. Instead, many programming language researchers choose to work on a smaller, more expressive language the lambda calculus. 21

The lambda calculus The lambda calculus is the smallest programming language imaginable. It was originally introduced by Alonzo Church (1930 s) as a foundation for mathematics but surprisingly, it perfectly captures computation! There are only three constructs: e ::= x (variables) e e (application) λx. e (abstraction) 22

The lambda calculus examples and conventions Example terms: λx. x x λx. (λy. x z) (λx. x a) Note: application associates to the left: a b c = (a b) c Note: only unary functions and unary application but we sometimes write λx y. e for λx. λy. e. Note: the function body of a lambda extends as far as possible to the right: λx. e f should be read as λx. (e f). 23

Bound and free variables An abstraction λx. e binds variable x in its body e. An occurrence of a variable that is not bound by a lambda is called free. Examples: x occurs free in λy. y (λz. x) (λx. x z) y x has one bound and one free occurrence of x. A term without free variables is called a closed term. 24 We consider two lambda terms that are equal, up to renaming of bound variables, equivalent (or more formally α-equivalent).

Equivalence examples For example, the following two terms are equivalent: λx. λt. x y t λz. λu. z y u But these are both different from: λa. λs. a z s we can only rename the bound variables. 25

λ-calculus: β-reduction A term of the form λx. e is called an abstraction or lambda binding; e is called the abstraction s body. The central rewrite rule of the λ-calculus is β-reduction: (λx. e) a β e [x 7 a] [x 7 a] := substitution of all free occurrences of variable x by a (λf. λx. λy. f y x) a b c β (λx. λy. a y x) b c β (λy. a y b) c β a c b 26 An expression of the form (λx. e) (t) is called a β-redex.

β-reduction: properties The definition of beta-reduction should be familiar from any other programming language: it allows you to fill in the arguments of a function call in the function s body. In that sense, the lambda calculus really is a tiny programming language! Beta reduction has several properties: arguments are consumed one by one functions are gradually destroyed when applied function definitions do not live in a separate space 27

λ-calculus: Name Capturing and α-conversion Consider the following example: (λy. (λb. y b)) a β (λb. y b) [y 7 a] = λb. a b And now we can reduce the following equivalent expression: (λy. (λa. y a)) a β (λa. y a) [y 7 a] = λa. a a What went wrong? Two equivalent expressions produced different results! 28

Capture avoiding substitution The substitution [x 7 y] must be a capture-avoiding substitution that is, it should renames the abstraction variable if necessary: (λy. (λa. y a)) a β (λa. y a) [y 7 a] α (λa. y a ) [y 7 a] = λa. a a Note that we introduce an explicit α-conversion step, renaming a to a. 29

Capture avoiding substitution We can define such a capture avoiding substitution as follows: x [x 7 t] = t y [x 7 t] = y when x y (t 1 t 2 ) [x 7 t] = (t 1 [x 7 t]) (t 2 [x 7 t]) (λy. s) [x 7 t] = λy. s [x 7 t] provided y x and y does not occur free in t. Note that this last rule may require α-renaming the variable y in order to proceed with the substitution. 30