CS345H: Programming Languages Lecture 8: Operational Semantics II 1/29 I Will Look at One More Formalism for Specifying Meaning Today

CS345H: Programming Languages

Lecture 8: Operational Semantics II

Thomas Dillig

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 1/29 I Will look at one more formalism for specifying meaning today

Outline

I We will discuss semantics of remining (interesting) L expressions

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 2/29 Outline

I We will discuss semantics of remining (interesting) L expressions

I Will look at one more formalism for specifying meaning today

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 2/29 I Let’s start with the if expression: if e1 then e2 else e3.

I Recall meaning: If e1 evaluates to a non-zero integer, the meaning of the expression is e2, otherwise e3

I Any ideas on how to write this as an operational semantics rule?

Back to Operational Semantics

I We are still missing semantics for key constructs in the L programming language

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 3/29 I Recall meaning: If e1 evaluates to a non-zero integer, the meaning of the expression is e2, otherwise e3

I Any ideas on how to write this as an operational semantics rule?

Back to Operational Semantics

I We are still missing semantics for key constructs in the L programming language

I Let’s start with the if expression: if e1 then e2 else e3.

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 3/29 I Any ideas on how to write this as an operational semantics rule?

Back to Operational Semantics

I We are still missing semantics for key constructs in the L programming language

I Let’s start with the if expression: if e1 then e2 else e3.

I Recall meaning: If e1 evaluates to a non-zero integer, the meaning of the expression is e2, otherwise e3

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 3/29 Back to Operational Semantics

I We are still missing semantics for key constructs in the L programming language

I Let’s start with the if expression: if e1 then e2 else e3.

I Recall meaning: If e1 evaluates to a non-zero integer, the meaning of the expression is e2, otherwise e3

I Any ideas on how to write this as an operational semantics rule?

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 3/29 E ` e1 : 0 0 E ` e3 : e 0 E ` if e1 then e2 else e3 : e

I Solution: Write two rules, one for the case where e1 evaluates to 0 and one for the case whenre e1 evaluates to a non-zero integer.

I What if e1 evaluates to 0?

Operational Semantics of Conditionals

I Diﬃculty: What happens depends on whether e1 evaluates to 0 or not.

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 4/29 E ` e1 : 0 0 E ` e3 : e 0 E ` if e1 then e2 else e3 : e

I What if e1 evaluates to 0?

Operational Semantics of Conditionals

I Diﬃculty: What happens depends on whether e1 evaluates to 0 or not.

I Solution: Write two rules, one for the case where e1 evaluates to 0 and one for the case whenre e1 evaluates to a non-zero integer.

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 4/29 E ` e1 : 0 0 E ` e3 : e 0 E ` if e1 then e2 else e3 : e

Operational Semantics of Conditionals

I Diﬃculty: What happens depends on whether e1 evaluates to 0 or not.

I Solution: Write two rules, one for the case where e1 evaluates to 0 and one for the case whenre e1 evaluates to a non-zero integer.

I What if e1 evaluates to 0?

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 4/29 Operational Semantics of Conditionals

I Diﬃculty: What happens depends on whether e1 evaluates to 0 or not.

I Solution: Write two rules, one for the case where e1 evaluates to 0 and one for the case whenre e1 evaluates to a non-zero integer.

I What if e1 evaluates to 0?

E ` e1 : 0 0 E ` e3 : e 0 E ` if e1 then e2 else e3 : e

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 4/29 E ` e1 : non-zero integer 0 E ` e2 : e 0 E ` if e1 then e2 else e3 : e

I Upshot: Can encode choice by giving multiple rules for same construct

I But need to make sure at most one rule can apply at any point for deterministic semantics

I Deterministic Semantics: Every program evaluates to at most one value

Operational Semantics of Conditionals Cont.

I What if e1 evaluates to a non-zero integer?

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 5/29 I Upshot: Can encode choice by giving multiple rules for same construct

I But need to make sure at most one rule can apply at any point for deterministic semantics

I Deterministic Semantics: Every program evaluates to at most one value

Operational Semantics of Conditionals Cont.

I What if e1 evaluates to a non-zero integer?

E ` e1 : non-zero integer 0 E ` e2 : e 0 E ` if e1 then e2 else e3 : e

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 5/29 I But need to make sure at most one rule can apply at any point for deterministic semantics

I Deterministic Semantics: Every program evaluates to at most one value

Operational Semantics of Conditionals Cont.

I What if e1 evaluates to a non-zero integer?

E ` e1 : non-zero integer 0 E ` e2 : e 0 E ` if e1 then e2 else e3 : e

I Upshot: Can encode choice by giving multiple rules for same construct

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 5/29 I Deterministic Semantics: Every program evaluates to at most one value

Operational Semantics of Conditionals Cont.

I What if e1 evaluates to a non-zero integer?

E ` e1 : non-zero integer 0 E ` e2 : e 0 E ` if e1 then e2 else e3 : e

I Upshot: Can encode choice by giving multiple rules for same construct

I But need to make sure at most one rule can apply at any point for deterministic semantics

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 5/29 Operational Semantics of Conditionals Cont.

I What if e1 evaluates to a non-zero integer?

E ` e1 : non-zero integer 0 E ` e2 : e 0 E ` if e1 then e2 else e3 : e

I Upshot: Can encode choice by giving multiple rules for same construct

I But need to make sure at most one rule can apply at any point for deterministic semantics

I Deterministic Semantics: Every program evaluates to at most one value

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 5/29 I To define the meaning of a function definition, we can either repeat the lambda and let binding rules in one rule or rewrite the function definition into let and lambda’s and invoke the existing rules

I We will do the latter:

E ` let f = lambda x1.... lambda xn .e1 in e2 : e E ` fun f with x1,..., xn = e1 in e2 : e

I This only works if there are no circular reductions!

Operational Semantics of Function Deﬁnitions

I Recall: In L, function deﬁnitions of the form fun f with x1,...,xn=e in... are equivalent to let f = lambda x1...lambda xn.e in ...

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 6/29 I We will do the latter:

E ` let f = lambda x1.... lambda xn .e1 in e2 : e E ` fun f with x1,..., xn = e1 in e2 : e

I This only works if there are no circular reductions!

Operational Semantics of Function Deﬁnitions

I Recall: In L, function deﬁnitions of the form fun f with x1,...,xn=e in... are equivalent to let f = lambda x1...lambda xn.e in ...

I To define the meaning of a function definition, we can either repeat the lambda and let binding rules in one rule or rewrite the function definition into let and lambda’s and invoke the existing rules

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 6/29 I This only works if there are no circular reductions!

Operational Semantics of Function Deﬁnitions

I Recall: In L, function deﬁnitions of the form fun f with x1,...,xn=e in... are equivalent to let f = lambda x1...lambda xn.e in ...

I We will do the latter:

E ` let f = lambda x1.... lambda xn .e1 in e2 : e E ` fun f with x1,..., xn = e1 in e2 : e

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 6/29 Operational Semantics of Function Deﬁnitions

I Recall: In L, function deﬁnitions of the form fun f with x1,...,xn=e in... are equivalent to let f = lambda x1...lambda xn.e in ...

I We will do the latter:

E ` let f = lambda x1.... lambda xn .e1 in e2 : e E ` fun f with x1,..., xn = e1 in e2 : e

I This only works if there are no circular reductions!

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 6/29 I Consider the following grammar for a list of integers:

S → [E] E → int E | int

I Example strings in L(S): [3], [2 3 4], [1 3],...

I Suppose we want to deﬁne the meaning of a list of integers as their sum: How can we write operational semantics for this mini-language?

Operational Semantics of Variable-Length Expressions

I The trick we just used to give meaning to function deﬁnitions is also useful for giving meaning to variable-length expressions.

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 7/29 I Example strings in L(S): [3], [2 3 4], [1 3],...

I Suppose we want to deﬁne the meaning of a list of integers as their sum: How can we write operational semantics for this mini-language?

Operational Semantics of Variable-Length Expressions

I The trick we just used to give meaning to function deﬁnitions is also useful for giving meaning to variable-length expressions.

I Consider the following grammar for a list of integers:

S → [E] E → int E | int

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 7/29 I Suppose we want to deﬁne the meaning of a list of integers as their sum: How can we write operational semantics for this mini-language?

Operational Semantics of Variable-Length Expressions

I The trick we just used to give meaning to function deﬁnitions is also useful for giving meaning to variable-length expressions.

I Consider the following grammar for a list of integers:

S → [E] E → int E | int

I Example strings in L(S): [3], [2 3 4], [1 3],...

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 7/29 Operational Semantics of Variable-Length Expressions

I The trick we just used to give meaning to function deﬁnitions is also useful for giving meaning to variable-length expressions.

I Consider the following grammar for a list of integers:

S → [E] E → int E | int

I Example strings in L(S): [3], [2 3 4], [1 3],...

I Suppose we want to deﬁne the meaning of a list of integers as their sum: How can we write operational semantics for this mini-language?

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 7/29 ` [i1 i2]: i1 + i2

I Let’s write operational semantics for a list of length 2:

I Solution: Think recursively! The sum of a list of k integers can be obtained by removing the ﬁrst integer, computing the sum of the remainder and adding the two values

I This translates into two rules: Base case and inductive case

Operational Semantics of Variable-Length Expressions

I Observation: Diﬃculty caused by unknown length of list

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 8/29 ` [i1 i2]: i1 + i2

I Solution: Think recursively! The sum of a list of k integers can be obtained by removing the ﬁrst integer, computing the sum of the remainder and adding the two values

I This translates into two rules: Base case and inductive case

Operational Semantics of Variable-Length Expressions

I Observation: Diﬃculty caused by unknown length of list

I Let’s write operational semantics for a list of length 2:

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 8/29 I Solution: Think recursively! The sum of a list of k integers can be obtained by removing the ﬁrst integer, computing the sum of the remainder and adding the two values

I This translates into two rules: Base case and inductive case

Operational Semantics of Variable-Length Expressions

I Observation: Diﬃculty caused by unknown length of list

I Let’s write operational semantics for a list of length 2:

` [i1 i2]: i1 + i2

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 8/29 I This translates into two rules: Base case and inductive case

Operational Semantics of Variable-Length Expressions

I Observation: Diﬃculty caused by unknown length of list

I Let’s write operational semantics for a list of length 2:

` [i1 i2]: i1 + i2

I Solution: Think recursively! The sum of a list of k integers can be obtained by removing the ﬁrst integer, computing the sum of the remainder and adding the two values

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 8/29 Operational Semantics of Variable-Length Expressions

I Observation: Diﬃculty caused by unknown length of list

I Let’s write operational semantics for a list of length 2:

` [i1 i2]: i1 + i2

I Solution: Think recursively! The sum of a list of k integers can be obtained by removing the ﬁrst integer, computing the sum of the remainder and adding the two values

I This translates into two rules: Base case and inductive case

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 8/29 ` [R]: i2 ` [i1, R]: i1 + i2

` [i]: i

I Inductive Case: List with at least two integers

I Upshot: To give semantics to variable-length expression, decompose recursively into inductive case(s) and base case(s)

I Observe that it is possible to encode computation in this formalism, we will (brieﬂy) see this again towards the end of the class

Operational Semantics of Variable-Length Expressions

I Base case: List with one integer

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 9/29 ` [R]: i2 ` [i1, R]: i1 + i2

I Inductive Case: List with at least two integers

I Upshot: To give semantics to variable-length expression, decompose recursively into inductive case(s) and base case(s)

I Observe that it is possible to encode computation in this formalism, we will (brieﬂy) see this again towards the end of the class

Operational Semantics of Variable-Length Expressions

I Base case: List with one integer

` [i]: i

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 9/29 ` [R]: i2 ` [i1, R]: i1 + i2

I Upshot: To give semantics to variable-length expression, decompose recursively into inductive case(s) and base case(s)

I Observe that it is possible to encode computation in this formalism, we will (brieﬂy) see this again towards the end of the class

Operational Semantics of Variable-Length Expressions

I Base case: List with one integer

` [i]: i

I Inductive Case: List with at least two integers

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 9/29 I Upshot: To give semantics to variable-length expression, decompose recursively into inductive case(s) and base case(s)

I Observe that it is possible to encode computation in this formalism, we will (brieﬂy) see this again towards the end of the class

Operational Semantics of Variable-Length Expressions

I Base case: List with one integer

` [i]: i

I Inductive Case: List with at least two integers

` [R]: i2 ` [i1, R]: i1 + i2

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 9/29 I Observe that it is possible to encode computation in this formalism, we will (brieﬂy) see this again towards the end of the class

Operational Semantics of Variable-Length Expressions

I Base case: List with one integer

` [i]: i

I Inductive Case: List with at least two integers

` [R]: i2 ` [i1, R]: i1 + i2

I Upshot: To give semantics to variable-length expression, decompose recursively into inductive case(s) and base case(s)

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 9/29 Operational Semantics of Variable-Length Expressions

I Base case: List with one integer

` [i]: i

I Inductive Case: List with at least two integers

` [R]: i2 ` [i1, R]: i1 + i2

I Upshot: To give semantics to variable-length expression, decompose recursively into inductive case(s) and base case(s)

I Observe that it is possible to encode computation in this formalism, we will (brieﬂy) see this again towards the end of the class

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 9/29 I Are these two semantics equivalent?

Alternative Semantics

I We can also deﬁne the meaning of a list program as follows: Base case: ` i : i Inductive case: ` e1 : i1 `: e2 : i2 ` e1 + e2 : i1 + i2 Removing the brackets: ` e : i ` [e]: i

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 10/29 Alternative Semantics

I We can also deﬁne the meaning of a list program as follows: Base case: ` i : i Inductive case: ` e1 : i1 `: e2 : i2 ` e1 + e2 : i1 + i2 Removing the brackets: ` e : i ` [e]: i

I Are these two semantics equivalent?

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 10/29 0 E ` e1 : lambda x.e1 0 E ` e1[e2/x]: e E ` (e R): e0 0 E ` (e1 e2 R): e

I But the application can have any number of expressions in L. Example: (x y z) is a valid L expression with meaning ((x y) z)

I Solution: Write inductive case for more than two expressions!

Operational Semantics of Application in L

I Last time we only gave operational semantics for the application base case: Two expressions: 0 E ` e1 : lambda x. e1 0 E ` e1[e2/x]: e E ` (e1 e2): e

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 11/29 0 E ` e1 : lambda x.e1 0 E ` e1[e2/x]: e E ` (e R): e0 0 E ` (e1 e2 R): e

I Solution: Write inductive case for more than two expressions!

Operational Semantics of Application in L

I Last time we only gave operational semantics for the application base case: Two expressions: 0 E ` e1 : lambda x. e1 0 E ` e1[e2/x]: e E ` (e1 e2): e

I But the application can have any number of expressions in L. Example: (x y z) is a valid L expression with meaning ((x y) z)

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 11/29 0 E ` e1 : lambda x.e1 0 E ` e1[e2/x]: e E ` (e R): e0 0 E ` (e1 e2 R): e

Operational Semantics of Application in L

I Last time we only gave operational semantics for the application base case: Two expressions: 0 E ` e1 : lambda x. e1 0 E ` e1[e2/x]: e E ` (e1 e2): e

I But the application can have any number of expressions in L. Example: (x y z) is a valid L expression with meaning ((x y) z)

I Solution: Write inductive case for more than two expressions!

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 11/29 Operational Semantics of Application in L

I Last time we only gave operational semantics for the application base case: Two expressions: 0 E ` e1 : lambda x. e1 0 E ` e1[e2/x]: e E ` (e1 e2): e

I But the application can have any number of expressions in L. Example: (x y z) is a valid L expression with meaning ((x y) z)

I Solution: Write inductive case for more than two expressions! 0 E ` e1 : lambda x.e1 0 E ` e1[e2/x]: e E ` (e R): e0 0 E ` (e1 e2 R): e

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 11/29 I This is not an application

I Observe: L syntax allows this to indicate associativity and precedence

I Question: What is the meaning (operational semantics rule) for (x)?

I Answer: E ` e : e0 E ` (e): e0

Operational Semantics of Application in L

I What about an application with one expression, such as (x)?

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 12/29 I Observe: L syntax allows this to indicate associativity and precedence

I Question: What is the meaning (operational semantics rule) for (x)?

I Answer: E ` e : e0 E ` (e): e0

Operational Semantics of Application in L

I What about an application with one expression, such as (x)?

I This is not an application

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 12/29 I Question: What is the meaning (operational semantics rule) for (x)?

I Answer: E ` e : e0 E ` (e): e0

Operational Semantics of Application in L

I What about an application with one expression, such as (x)?

I This is not an application

I Observe: L syntax allows this to indicate associativity and precedence

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 12/29 I Answer: E ` e : e0 E ` (e): e0

Operational Semantics of Application in L

I What about an application with one expression, such as (x)?

I This is not an application

I Observe: L syntax allows this to indicate associativity and precedence

I Question: What is the meaning (operational semantics rule) for (x)?

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 12/29 Operational Semantics of Application in L

I What about an application with one expression, such as (x)?

I This is not an application

I Observe: L syntax allows this to indicate associativity and precedence

I Question: What is the meaning (operational semantics rule) for (x)?

I Answer: E ` e : e0 E ` (e): e0

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 12/29 E ` e :[e1, e2] E `!e : e1

E ` e : e1 (e1 not a list) E `!e : e1

I Consider !e, which evaluated to the head of the list if e is a list and to e otherwise

I e is a list:

I e is not a list:

List Operations

I Let’s also take a brief look at semantics for some list operations:

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 13/29 E ` e :[e1, e2] E `!e : e1

E ` e : e1 (e1 not a list) E `!e : e1

I e is a list:

I e is not a list:

List Operations

I Let’s also take a brief look at semantics for some list operations:

I Consider !e, which evaluated to the head of the list if e is a list and to e otherwise

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 13/29 E ` e : e1 (e1 not a list) E `!e : e1

E ` e :[e1, e2] E `!e : e1

I e is not a list:

List Operations

I Let’s also take a brief look at semantics for some list operations:

I Consider !e, which evaluated to the head of the list if e is a list and to e otherwise

I e is a list:

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 13/29 E ` e : e1 (e1 not a list) E `!e : e1

I e is not a list:

List Operations

I Let’s also take a brief look at semantics for some list operations:

I Consider !e, which evaluated to the head of the list if e is a list and to e otherwise

I e is a list: E ` e :[e1, e2] E `!e : e1

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 13/29 E ` e : e1 (e1 not a list) E `!e : e1

List Operations

I Let’s also take a brief look at semantics for some list operations:

I Consider !e, which evaluated to the head of the list if e is a list and to e otherwise

I e is a list: E ` e :[e1, e2] E `!e : e1

I e is not a list:

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 13/29 List Operations

I Let’s also take a brief look at semantics for some list operations:

I Consider !e, which evaluated to the head of the list if e is a list and to e otherwise

I e is a list: E ` e :[e1, e2] E `!e : e1

I e is not a list: E ` e : e1 (e1 not a list) E `!e : e1

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 13/29 0 E ` e1 : e1 E ` e2 : Nil 0 E ` e1@e2 : e1

0 E ` e1 : e1 0 0 E ` e2 : e2(e2 not Nil) 0 0 E ` e1@e2 :[e1, e2]

I e2 evaluates to Nil:

List Operations

I What about e1@e2, which evaluated to the list [e1, e2]?

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 14/29 0 E ` e1 : e1 E ` e2 : Nil 0 E ` e1@e2 : e1

I e2 evaluates to Nil:

List Operations

I What about e1@e2, which evaluated to the list [e1, e2]?

0 E ` e1 : e1 0 0 E ` e2 : e2(e2 not Nil) 0 0 E ` e1@e2 :[e1, e2]

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 14/29 0 E ` e1 : e1 E ` e2 : Nil 0 E ` e1@e2 : e1

List Operations

I What about e1@e2, which evaluated to the list [e1, e2]?

0 E ` e1 : e1 0 0 E ` e2 : e2(e2 not Nil) 0 0 E ` e1@e2 :[e1, e2]

I e2 evaluates to Nil:

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 14/29 List Operations

I What about e1@e2, which evaluated to the list [e1, e2]?

0 E ` e1 : e1 0 0 E ` e2 : e2(e2 not Nil) 0 0 E ` e1@e2 :[e1, e2]

I e2 evaluates to Nil:

0 E ` e1 : e1 E ` e2 : Nil 0 E ` e1@e2 : e1

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 14/29 I For PA3, you will need to refer to the operational semantics of L in the manual to implement your interpreter.

I The manual is the oﬃcial source for the semantics of L, not the reference interpreter!

Congratulations!

I You can now understand every page in the L reference manual.

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 15/29 I The manual is the oﬃcial source for the semantics of L, not the reference interpreter!

Congratulations!

I You can now understand every page in the L reference manual.

I For PA3, you will need to refer to the operational semantics of L in the manual to implement your interpreter.

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 15/29 Congratulations!

I You can now understand every page in the L reference manual.

I For PA3, you will need to refer to the operational semantics of L in the manual to implement your interpreter.

I The manual is the oﬃcial source for the semantics of L, not the reference interpreter!

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 15/29 I They are called large step because each rule completely evaluates an expression, taking as many steps as necessary.

I Example: The plus rule

E ` e1 : i1 (integer) E ` e2 : i2 (integer) E ` e1 + e2 : i1 + i2

I Here, we evaluate both e1 and e2 to compute the ﬁnal value in one (big) step

I Alternate formalism for giving semantics: small-step operational semantics

Operational Semantics

I The rules we have written are known as large-step operational semantics

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 16/29 I Example: The plus rule

E ` e1 : i1 (integer) E ` e2 : i2 (integer) E ` e1 + e2 : i1 + i2

I Here, we evaluate both e1 and e2 to compute the ﬁnal value in one (big) step

I Alternate formalism for giving semantics: small-step operational semantics

Operational Semantics

I The rules we have written are known as large-step operational semantics

I They are called large step because each rule completely evaluates an expression, taking as many steps as necessary.

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 16/29 I Here, we evaluate both e1 and e2 to compute the ﬁnal value in one (big) step

I Alternate formalism for giving semantics: small-step operational semantics

Operational Semantics

I The rules we have written are known as large-step operational semantics

I They are called large step because each rule completely evaluates an expression, taking as many steps as necessary.

I Example: The plus rule

E ` e1 : i1 (integer) E ` e2 : i2 (integer) E ` e1 + e2 : i1 + i2

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 16/29 I Alternate formalism for giving semantics: small-step operational semantics

Operational Semantics

I The rules we have written are known as large-step operational semantics

I They are called large step because each rule completely evaluates an expression, taking as many steps as necessary.

I Example: The plus rule

E ` e1 : i1 (integer) E ` e2 : i2 (integer) E ` e1 + e2 : i1 + i2

I Here, we evaluate both e1 and e2 to compute the ﬁnal value in one (big) step

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 16/29 Operational Semantics

I The rules we have written are known as large-step operational semantics

I They are called large step because each rule completely evaluates an expression, taking as many steps as necessary.

I Example: The plus rule

E ` e1 : i1 (integer) E ` e2 : i2 (integer) E ` e1 + e2 : i1 + i2

I Here, we evaluate both e1 and e2 to compute the ﬁnal value in one (big) step

I Alternate formalism for giving semantics: small-step operational semantics

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 16/29 I You can think of SSOS as “decomposing” all operations that happen in one rule in LSOS into individual steps

I This means: Each rule in SSOS has at most one precondition

Small Step Operational Semantics

I Small-step operational semantics perform only one step of computation per rule invocation

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 17/29 I This means: Each rule in SSOS has at most one precondition

Small Step Operational Semantics

I Small-step operational semantics perform only one step of computation per rule invocation

I You can think of SSOS as “decomposing” all operations that happen in one rule in LSOS into individual steps

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 17/29 Small Step Operational Semantics

I Small-step operational semantics perform only one step of computation per rule invocation

I You can think of SSOS as “decomposing” all operations that happen in one rule in LSOS into individual steps

I This means: Each rule in SSOS has at most one precondition

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 17/29 I Rule 1: Adding two integers

hc1 + c2, Ei → hc1 + c2, Ei

I Rule 2: Reducing ﬁrst expression to an integer

0 he1, Ei → hc, E i 0 he1 + e2, Ei → hc + e2, E i

I Rule 3: Reducing second expression to an integer

0 he, Ei → hc2, E i 0 hc1 + e, Ei → hc1 + c2, E i

Small-step Operational Semantics

I SSOS are easiest understood by an example. Consider the integer plus in L written in SSOS:

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 18/29 I Rule 2: Reducing ﬁrst expression to an integer

0 he1, Ei → hc, E i 0 he1 + e2, Ei → hc + e2, E i

I Rule 3: Reducing second expression to an integer

0 he, Ei → hc2, E i 0 hc1 + e, Ei → hc1 + c2, E i

Small-step Operational Semantics

I SSOS are easiest understood by an example. Consider the integer plus in L written in SSOS:

I Rule 1: Adding two integers

hc1 + c2, Ei → hc1 + c2, Ei

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 18/29 I Rule 3: Reducing second expression to an integer

0 he, Ei → hc2, E i 0 hc1 + e, Ei → hc1 + c2, E i

Small-step Operational Semantics

I SSOS are easiest understood by an example. Consider the integer plus in L written in SSOS:

I Rule 1: Adding two integers

hc1 + c2, Ei → hc1 + c2, Ei

I Rule 2: Reducing ﬁrst expression to an integer

0 he1, Ei → hc, E i 0 he1 + e2, Ei → hc + e2, E i

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 18/29 Small-step Operational Semantics

I SSOS are easiest understood by an example. Consider the integer plus in L written in SSOS:

I Rule 1: Adding two integers

hc1 + c2, Ei → hc1 + c2, Ei

I Rule 2: Reducing ﬁrst expression to an integer

0 he1, Ei → hc, E i 0 he1 + e2, Ei → hc + e2, E i

I Rule 3: Reducing second expression to an integer

0 he, Ei → hc2, E i 0 hc1 + e, Ei → hc1 + c2, E i

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 18/29 I h(2 + 4) + 6, i → h6 + 6, i → h12, i

SSOS in Action

I Let’s use these rules to prove what the value of (2 + 4) + 6 is:

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 19/29 SSOS in Action

I Let’s use these rules to prove what the value of (2 + 4) + 6 is:

I h(2 + 4) + 6, i → h6 + 6, i → h12, i

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 19/29 I In contrast, LSOS have the `: notation (at least in this class)

I SSOS are really (conditional) rewrite rules

I The β reduction of λ-calculus is a small-step semantics rule

SSOS

I You can tell small-step operational semantics by the hi → notation

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 20/29 I SSOS are really (conditional) rewrite rules

I The β reduction of λ-calculus is a small-step semantics rule

SSOS

I You can tell small-step operational semantics by the hi → notation

I In contrast, LSOS have the `: notation (at least in this class)

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 20/29 I The β reduction of λ-calculus is a small-step semantics rule

SSOS

I You can tell small-step operational semantics by the hi → notation

I In contrast, LSOS have the `: notation (at least in this class)

I SSOS are really (conditional) rewrite rules

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 20/29 SSOS

I You can tell small-step operational semantics by the hi → notation

I In contrast, LSOS have the `: notation (at least in this class)

I SSOS are really (conditional) rewrite rules

I The β reduction of λ-calculus is a small-step semantics rule

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 20/29 0 0 he1[e2/x], Ei → he3, E i 0 0 h(lambda x.e1 e2), Ei → he3, E i

I What are equivalent SSOS?

SSOS of the Application

I Recall the large-step operational semantics:

0 E ` e1 : lambda x. e1 0 E ` e1[e2/x]: e E ` (e1 e2): e

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 21/29 0 0 he1[e2/x], Ei → he3, E i 0 0 h(lambda x.e1 e2), Ei → he3, E i

SSOS of the Application

I Recall the large-step operational semantics:

0 E ` e1 : lambda x. e1 0 E ` e1[e2/x]: e E ` (e1 e2): e

I What are equivalent SSOS?

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 21/29 SSOS of the Application

I Recall the large-step operational semantics:

0 E ` e1 : lambda x. e1 0 E ` e1[e2/x]: e E ` (e1 e2): e

I What are equivalent SSOS?

0 0 he1[e2/x], Ei → he3, E i 0 0 h(lambda x.e1 e2), Ei → he3, E i

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 21/29 I What about in SSOS?

I For SSOS, other rules will rewrite the expression until it 0 matches the form lambda x. e1

SSOS of the Application

I Recall the large-step operational semantics, evaluating e1 made a diﬀerence:

0 E ` e1 : lambda x. e1 0 E ` e1[e2/x]: e E ` (e1 e2): e

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 22/29 I For SSOS, other rules will rewrite the expression until it 0 matches the form lambda x. e1

SSOS of the Application

I Recall the large-step operational semantics, evaluating e1 made a diﬀerence:

0 E ` e1 : lambda x. e1 0 E ` e1[e2/x]: e E ` (e1 e2): e

I What about in SSOS?

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 22/29 SSOS of the Application

I Recall the large-step operational semantics, evaluating e1 made a diﬀerence:

0 E ` e1 : lambda x. e1 0 E ` e1[e2/x]: e E ` (e1 e2): e

I What about in SSOS?

I For SSOS, other rules will rewrite the expression until it 0 matches the form lambda x. e1

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 22/29 I But we want eager semantics: We want to evaluate e1 before adding to the environment.

I We want a rule that evaluates e1 as much as possible and only then applies the let rule:

I Notation: We will write be to indicate that expression e has been evaluated as much as possible.

SSOS of let

I First try: he2, E[x ← e1]i → he3, i hlet x = e1 in e2, Ei → he3, Ei

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 23/29 I We want a rule that evaluates e1 as much as possible and only then applies the let rule:

I Notation: We will write be to indicate that expression e has been evaluated as much as possible.

SSOS of let

I First try: he2, E[x ← e1]i → he3, i hlet x = e1 in e2, Ei → he3, Ei

I But we want eager semantics: We want to evaluate e1 before adding to the environment.

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 23/29 I Notation: We will write be to indicate that expression e has been evaluated as much as possible.

SSOS of let

I First try: he2, E[x ← e1]i → he3, i hlet x = e1 in e2, Ei → he3, Ei

I But we want eager semantics: We want to evaluate e1 before adding to the environment.

I We want a rule that evaluates e1 as much as possible and only then applies the let rule:

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 23/29 SSOS of let

I First try: he2, E[x ← e1]i → he3, i hlet x = e1 in e2, Ei → he3, Ei

I But we want eager semantics: We want to evaluate e1 before adding to the environment.

I We want a rule that evaluates e1 as much as possible and only then applies the let rule:

I Notation: We will write be to indicate that expression e has been evaluated as much as possible.

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 23/29 he2, E[x ← eb1]i → he2, i hlet x = eb1 in e2, Ei → he3, Ei

0 he1, Ei → heb1, E i 0 hlet x = e1 in e2, Ei → hlet x = eb1 in e2, E i

SSOS of let cont.

I Here are the two rules for eager let in SSOS:

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 24/29 SSOS of let cont.

I Here are the two rules for eager let in SSOS:

he2, E[x ← eb1]i → he2, i hlet x = eb1 in e2, Ei → he3, Ei

0 he1, Ei → heb1, E i 0 hlet x = e1 in e2, Ei → hlet x = eb1 in e2, E i

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 24/29 I This means any derivation is a tree.

I In small-step semantics, each rule only performs one step of computation

I This means any derivation is a line

Small-step vs. Big-step Semantics

I In big-step semantics, any rule may invoke any number of other rules in the hypothesis

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 25/29 I In small-step semantics, each rule only performs one step of computation

I This means any derivation is a line

Small-step vs. Big-step Semantics

I In big-step semantics, any rule may invoke any number of other rules in the hypothesis

I This means any derivation is a tree.

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 25/29 I This means any derivation is a line

Small-step vs. Big-step Semantics

I In big-step semantics, any rule may invoke any number of other rules in the hypothesis

I This means any derivation is a tree.

I In small-step semantics, each rule only performs one step of computation

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 25/29 Small-step vs. Big-step Semantics

I In big-step semantics, any rule may invoke any number of other rules in the hypothesis

I This means any derivation is a tree.

I In small-step semantics, each rule only performs one step of computation

I This means any derivation is a line

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 25/29 I Recall: In BSOS, encountering an undeﬁned expression, such as 3+"duck" got us “stuck”, i.e., we could never satisfy the hypothesis to reach a conclusion

I In SSOS, undeﬁned expressions also get stuck,i.e. no rule applies

Advantages of SSOS

I The main advantage of SSOS is that it allows us to distinguish between non-terminating computation and undeﬁned computation

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 26/29 I In SSOS, undeﬁned expressions also get stuck,i.e. no rule applies

Advantages of SSOS

I The main advantage of SSOS is that it allows us to distinguish between non-terminating computation and undeﬁned computation

I Recall: In BSOS, encountering an undeﬁned expression, such as 3+"duck" got us “stuck”, i.e., we could never satisfy the hypothesis to reach a conclusion

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 26/29 Advantages of SSOS

I The main advantage of SSOS is that it allows us to distinguish between non-terminating computation and undeﬁned computation

I Recall: In BSOS, encountering an undeﬁned expression, such as 3+"duck" got us “stuck”, i.e., we could never satisfy the hypothesis to reach a conclusion

I In SSOS, undeﬁned expressions also get stuck,i.e. no rule applies

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 26/29 I In BSOS, we will “get stuck”, i.e. we will never satisfy all hypothesis of the function invocation

I In SSOS, we will have an inﬁnite derivation line

I Upshot: SSOS allow us to distinguish non-termination from errors

Advantages of SSOS Cont.

I But, consider the following program: fun f with x = (f x) in (f 1).

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 27/29 I In SSOS, we will have an inﬁnite derivation line

I Upshot: SSOS allow us to distinguish non-termination from errors

Advantages of SSOS Cont.

I But, consider the following program: fun f with x = (f x) in (f 1).

I In BSOS, we will “get stuck”, i.e. we will never satisfy all hypothesis of the function invocation

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 27/29 I Upshot: SSOS allow us to distinguish non-termination from errors

Advantages of SSOS Cont.

I But, consider the following program: fun f with x = (f x) in (f 1).

I In BSOS, we will “get stuck”, i.e. we will never satisfy all hypothesis of the function invocation

I In SSOS, we will have an inﬁnite derivation line

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 27/29 Advantages of SSOS Cont.

I But, consider the following program: fun f with x = (f x) in (f 1).

I In BSOS, we will “get stuck”, i.e. we will never satisfy all hypothesis of the function invocation

I In SSOS, we will have an inﬁnite derivation line

I Upshot: SSOS allow us to distinguish non-termination from errors

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 27/29 I This allows us to talk about (some) notions of complexity when analyzing small-step semantics

I Main disadvantage of small step semantics is that they are less intuitive and and usually harder to write

I SSOS also always force one order, even if we would like to leave an order undeﬁned

Big vs. Small-Step Semantics

I The other big diﬀerence is that we can quantify the cost of a computation with the number of steps in a small-step derivation

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 28/29 I Main disadvantage of small step semantics is that they are less intuitive and and usually harder to write

I SSOS also always force one order, even if we would like to leave an order undeﬁned

Big vs. Small-Step Semantics

I The other big diﬀerence is that we can quantify the cost of a computation with the number of steps in a small-step derivation

I This allows us to talk about (some) notions of complexity when analyzing small-step semantics

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 28/29 I SSOS also always force one order, even if we would like to leave an order undeﬁned

Big vs. Small-Step Semantics

I The other big diﬀerence is that we can quantify the cost of a computation with the number of steps in a small-step derivation

I This allows us to talk about (some) notions of complexity when analyzing small-step semantics

I Main disadvantage of small step semantics is that they are less intuitive and and usually harder to write

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 28/29 Big vs. Small-Step Semantics

I The other big diﬀerence is that we can quantify the cost of a computation with the number of steps in a small-step derivation

I This allows us to talk about (some) notions of complexity when analyzing small-step semantics

I Main disadvantage of small step semantics is that they are less intuitive and and usually harder to write

I SSOS also always force one order, even if we would like to leave an order undeﬁned

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 28/29 I There are at least two more in common use: Denotational Semantics and Axiomatic Semantics

I However, operational semantics seem to be winning the “semantics wars”

I Why: Easier to understand and easier to prove (most) properties with them

Conclusion

I We have seen two formalisms for specifying meaning of programs

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 29/29 I However, operational semantics seem to be winning the “semantics wars”

I Why: Easier to understand and easier to prove (most) properties with them

Conclusion

I We have seen two formalisms for specifying meaning of programs

I There are at least two more in common use: Denotational Semantics and Axiomatic Semantics

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 29/29 I Why: Easier to understand and easier to prove (most) properties with them

Conclusion

I We have seen two formalisms for specifying meaning of programs

I There are at least two more in common use: Denotational Semantics and Axiomatic Semantics

I However, operational semantics seem to be winning the “semantics wars”

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 29/29 Conclusion

I We have seen two formalisms for specifying meaning of programs

I There are at least two more in common use: Denotational Semantics and Axiomatic Semantics

I However, operational semantics seem to be winning the “semantics wars”

I Why: Easier to understand and easier to prove (most) properties with them

Thomas Dillig, CS345H: Programming Languages Lecture 8: Operational Semantics II 29/29