Inductive Definitions

1. Inductive Definitions COS 510 David Walker

2. Inductive Definitions Inductive definitions play a central role in the study of programming languages They specify the following aspects of a language: • Concrete syntax (via CFGs) • Abstract syntax (via CFGs/ML datatypes) • Static semantics (via typing rules) • Dynamic semantics (via evaluation rules)

3. Reading • Read Pierce’s Text: • Chapter 2 (skim definitions; understand 2.4) • we will use sets, relations, functions, sequences • you should know basics such as mathematical induction, reflexivity, transitivity, symmetry, total and partial orders, domains and ranges of functions, etc. • Chapter 3

4. Inductive Definitions • An inductive definition consists of: • One or more judgments(ie:assertions) • A set of rules for deriving these judgments • For example: • Judgment is “n nat” • Rules: • zero nat • if n nat, then succ(n) nat.

5. Inference Rule Notation Inference rules are normally written as: where J and J1,..., Jn are judgements. (For axioms, n = 0.) J1 ... Jn J

6. An example For example, the rules for deriving n nat are usually written: zero nat n nat succ(n) nat

7. Derivation of Judgments • A judgment J is derivable iff either • there is an axiom • or there is a rule • such that J1, ..., Jn are derivable J J1 ... Jn J

8. Derivation of Judgments • We may determine whether a judgment is derivable by working backwards. • For example, the judgment succ(succ(zero)) nat is derivable as follows: optional: names of rules used at each step a derivation (ie: a proof) (zero) zero nat succ(zero) nat succ(succ(zero)) nat (succ) (succ)

9. Binary Trees • Here is a set of rules defining the judgment t tree stating that t is a binary tree: • Prove that the following is a valid judgment: node(empty, node(empty, empty)) tree t1 tree t2 tree node (t1, t2) tree empty tree

10. Rule Induction • By definition, every derivable judgment • is the consequence of some rule... • whose premises are derivable • That is, the rules are an exhaustive description of the derivable judgments • Just like an ML datatype definition is an exhaustive description of all the objects in the type being defined

11. Rule Induction • To show that every derivable judgment has a property P, it is enough to show that • For every rule, if J1, ..., Jn have the property P, then J has property P This is the principal of rule induction. J1 ... Jn J

12. Example: Natural Numbers • Consider the rules for n nat • We can prove that the property P holds of every n such that n nat by rule induction: • Show that P holds of zero; • Assuming that P holds of n, show that P holds of succ(n). • This is just ordinary mathematical induction!!

13. Example: Binary Tree • Similarly, we can prove that every binary tree t has a property P by showing that • empty has property P; • If t1 has property P and t2 has property P, then node(t1, t2) has property P. • This might be called tree induction.

14. Example: The Height of a Tree • Consider the following equations: • hgt(empty) = 0 • hgt(node(t1, t2)) = 1 + max(hgt(t1), hgt(t2)) • Claim: for every binary tree t there exists a unique integer n such that hgt(t) = n. • That is, the above equations define a function.

15. Example: The Height of a Tree • We will prove the claim by rule induction: • If t is derivable by the axiom • then n = 0 is determined by the first equation: hgt(empty) = 0 • is it unique? Yes. empty tree

16. Example: The Height of a Tree • If t is derivable by the rule then we may assume that: • exists a unique n1 such that hgt(t1) = n1; • exists a unique n2 such that hgt(t2) = n2; Hence, there exists a unique n, namely 1+max(n1, n2) such that hgt(t) = n. t1 tree t2 tree node (t1, t2) tree

17. Example: The Height of a Tree This is awfully pedantic, but it is useful to see the details at least once. • It is not obvious a priori that a tree has a well-defined height! • Rule induction justified the existence of the function hgt. It is “obvious” from the equations that there is at most one n such that hgt(t) = n. The proof shows that there exists at least one.

18. Inductive Definitions in PL • In this course, we will be looking at inductive definitions that determine • abstract syntax • static semantics (typing) • dynamic semantics (evaluation) • other properties of programs and programming languages

19. Inductive Definitions First up: Syntax

20. Abstract vs Concrete Syntax • the concrete syntax of a program is a string of characters: • ‘(’ ‘3’ ‘+’ ‘2’ ‘)’ ‘*’ ‘7’ • the abstract syntax of a program is a tree representing the computationally relevant portion of the program: * + 7 3 2

21. Abstract vs Concrete Syntax • the concrete syntax of a program contains many elements necessary for parsing: • parentheses • delimiters for comments • rules for precedence of operators • the abstract syntax of a program is much simpler; it does not contain these elements • precedence is given directly by the tree structure

22. Abstract vs Concrete Syntax • in this class, we work with abstract syntax • we want to define what programs mean • will work with the simple ASTs • nevertheless, we need a notation for writing down abstract syntax trees • when we write (3 + 2) * 7, you should visualize the tree: * + 7 3 2

23. Arithmetic Expressions, Informally • Informally, an arithmetic expression e is • a boolean value • an if statement (if e1 then e2 else e3) • the number zero • the successor of a number • the predecessor of a number • a test for zero (isZero e)

24. Arithmetic Expressions, Formally • An arithmetic expression e is • a boolean value: • an if statement (if e1 then e2 else e3): true exp false exp t1 exp t2 exp t3 exp if t1 then t2 else t3 exp

25. Arithmetic Expressions, formally • An arithmetic expression e is • a boolean, an if statement, a zero, a successor, a predecessor or a 0 test: e1 exp e2 exp e3 exp if e1 then e2 else e3 exp true exp false exp zero exp e exp succ e exp e exp pred e exp e exp iszero e exp

26. BNF • Defining every bit of syntax by inductive definitions can be lengthy and tedious • Syntactic definitions are an especially simple form of inductive definition: • context insensitive • unary predicates • There is a very convenient abbreviation: BNF

27. Arithmetic Expressions, in BNF e ::= true | false | if e then e else e | 0 | succ e | pred e | iszero e pick a new letter (Greek symbol/word) to represent any object in the set of objects being defined separates alternatives (7 alternatives implies 7 inductive rules) subterm/ subobject is any “e” object

28. An alternative definition b ::= true | false e ::= b | if e then e else e | 0 | succ e | pred e | iszero e corresponds to two inductively defined judgements: 2. e exp 1. b bool b bool b exp the key rule is an inclusion of booleans in expressions:

29. Metavariables b ::= true | false e ::= b | if e then e else e | 0 | succ e | pred e | iszero e • b and e are called metavariables • they stand for classes of objects, programs, and other things • they must not be confused with program variables

30. 2 Functions defined over Terms constants(true) = {true} constants (false) = {false} constants (0) = {0} constants(succ e) = constants(pred e) = constants(iszero e) = constants e constants (if e1 then e2 else e3) = Ui=1-3 (constants ei) size(true) = 1 size(false) = 1 size(0) = 1 size(succ e) = size(pred e) = size(iszero e) = size e + 1 size(if e1 then e2 else e3) = Ui=1-3 (size ei) +1

31. A Lemma • The number of distinct constants in any expression e is no greater than the size of e: | constants e | ≤ size e • How to prove it?

32. A Lemma • The number of distinct constants in any expression e is no greater than the size of e: | constants e | ≤ size e • How to prove it? • By rule induction on the rules for “e exp” • More commonly called induction on the structure of e • a form of “structural induction”

33. Structural Induction • Suppose P is a predicate on expressions. • structural induction: • for each expression e, we assume P(e’) holds for each subexpression e’ of e and go on to prove P(e) • result: we know P(e) for all expressions e • you’ll use this idea every single week in the rest of the course.

34. Back to the Lemma • The number of distinct constants in any expression e is no greater than the size of e: | constants e | ≤ size e • Proof: By induction on the structure of e. case e is 0, true, false: ... case e is succ e’, pred e’, iszero e’: ... case e is (if e1 then e2 else e3): ... always state method first separate cases (1 case per rule)

35. The Lemma • Lemma: | constants e | ≤ size e • Proof: ... case e is 0, true, false: | constants e | = |{e}| (by def of constants) = 1 (simple calculation) = size e (by def of size) 2-column proof calculation justification

36. A Lemma • Lemma: | constants e | ≤ size e ... case e is pred e’: | constants e | = |constants e’| (def of constants) ≤ size e’ (IH) < size e (by def of size)

37. A Lemma • Lemma: | constants e | ≤ size e ... case e is (if e1 then e2 else e3): | constants e | = |Ui=1..3 constants ei| (def of constants) ≤ Sumi=1..3 |constants ei| (property of sets) ≤ Sumi=1..3 (size ei) (IH on each ei) < size e (def of size)

38. A Lemma • Lemma: | constants e | ≤ size e ... other cases are similar. QED this had better be true use Latin to show off 

39. A Lemma • In reality, this lemma is so simple that you might not bother to write down all the details • “By induction on the structure of e.” is a sufficient statement • BUT, when you omit the details of a proof, you had better be sure it is trivial! • when in doubt, present the details. • NEVER hand-wave through a proof • it is better to admit you don’t know then to fake it • if you cannot do part of the proof for homework, explicitly state the part of the proof that fails (if I had lemma X here, then ...)

40. What is a proof? • A proof is an easily-checked justification of a judgment (ie: a theorem) • different people have different ideas about what “easily-checked” means • the more formal a proof, the more “easily-checked” • in this class, we have a pretty high bar • If there is one thing you’ll learn in this class, it is how to write a proof!

41. Inductive Definitions Next up: Evaluation

42. Evaluation • There are many different ways to formalize the evaluation of expressions • In this course we will use different sorts of operational semantics • direct expression of how an interpreter works • can be implemented in ML directly • easy to prove things about • scales up to complete languages easily

43. Values • A value is an object that has been completely evaluated • The values in our language of arithmetic expressions are v ::= true | false | zero | succ v • These values are a subset of the expressions • By calling “succ v” a value, we’re treating “succ v” like a piece of data; “succ v” is not function application • “succ zero” is a value that represents 1 • “succ (succ zero)” is the value that represents 2 • we are counting in unary • Remember, there is an inductive definition behind all this

44. Defining evaluation • single-step evaluation judgment: e  e’ • in English, we say “expression e evaluates to e’ in a single step”

45. Defining evaluation • single-step evaluation judgment: e  e’ • evaluation rules for booleans: if true then e2 else e3  e2 if false then e2 else e3  e3

46. Defining evaluation • single-step evaluation judgment: e  e’ • evaluation rules for booleans: if true then e2 else e3  e2 if false then e2 else e3  e3 what if the first position in the “if” is not true or false?

47. Defining evaluation • single-step evaluation judgment: e  e’ • evaluation rules for booleans: rules like this do the “real work” if true then e2 else e3  e2 if false then e2 else e3  e3 a “search” rule e1  e1’ if e1 then e2 else e3  if e1’ then e2 else e3

48. Defining evaluation • single-step evaluation judgment: e  e’ • evaluation rules for numbers: e  e’ succ e  succ e’ e  e’ pred e  pred e’ e  e’ iszero e  iszero e’ iszero (succ v)  false pred (succ v)  v iszero (zero)  true

49. Defining evaluation • single-step evaluation judgment: e  e’ • other evaluation rules: • there are none! • Consider the term iszero true • We call such terms stuck • They aren’t values, but no rule applies • They are nonsensical programs • An interpreter for our language will either raise an exception when it tries to evaluate a stuck program or maybe do something random or even crash! • It is a bad scene.

50. Defining evaluation • Multistep evaluation: e * e’ • In English: “e evaluates to e’ in some number of steps (possibly 0)”: e * e (reflexivity) e  e’’ e’’ * e’ e * e’ (transitivity)