Logic and Computation Lecture 4 Zena M. Ariola University of - PowerPoint PPT Presentation

Logic and Computation Lecture 4 Zena M. Ariola University of Oregon 24th Estonian Winter School in Computer Science, EWSCS ’19

Lessons learned Construction-destruction in programming How to implement strong reduction efficiently How to formulate join-point in an intermediate language Recursion and co-recursion A unifying theme for existing programming idioms: abstraction, session types, Church encodings, lazy evaluation and object-oriented programming Which connectives do you include in an intermediate language?

Two dual approaches to organize information

Data types Defined by rules of creation (constructors). Like algebraic data types in ML and Haskell data Either a b where Lef :: a ⊢ Either a b Right :: b ⊢ Either a b Producer: fixed shapes given by constructors Lef ( v 1 ) Right ( v 2 ) Consumer: case analysis on constructions µ [ Lef ( x ) . c 1 | Right ( y ) . c 2 ] ˜ case v { Lef ( x ) . v 1 | Right ( y ) . v 2 }

Co-data types Defined by rules of destruction (messages). codata a & b where π 1 : a & b ⊢ a π 2 : a & b ⊢ b Consumer: fixed shapes given by the destructors π 1 [ e 1 ] v .π 1 π 2 [ e 2 ] v .π 2 Producer: case analysis on destructors. “If I’m asked for first, do this” “If I’m asked for second, do that” µ ( π 1 [ α ] . c 1 | π 2 [ β ] . c 2 ) { π 1 → v 1 , π 2 → v 2 }

Church encodings and O-O Programming What do you want to do with a boolean?

Church encodings and O-O Programming What do you want to do with a boolean? If b then x else y codata Bool where If : Bool , a , a ⊢ a The producer will then patern match on the request: µ ( If ( x , y ) . v ) or using an OO-syntax { If ( x , y ) → v } True and false then become: { If ( x , y ) → x } { If ( x , y ) → y } With co-paterns: true . If x y = x false . If x y = y

Church encodings and O-O Programming What do you want to do with a boolean? If b then x else y codata Bool where If : Bool , a , a ⊢ a The producer will then patern match on the request: µ ( If ( x , y ) . v ) or using an OO-syntax { If ( x , y ) → v } True and false then become: { If ( x , y ) → x } { If ( x , y ) → y } With co-paterns: true . If x y = x false . If x y = y We arrive at the familiar encodings in the polymorphic λ -calculus: Bool = ∀ a . a → a → a true = Λ a .λ x : a .λ y : a . x false = Λ a .λ x : a .λ y : a . y

Church encodings and O-O Programming What do you want to do with a boolean? If b then x else y codata Bool where If : Bool , a , a ⊢ a The producer will then patern match on the request: µ ( If ( x , y ) . v ) or using an OO-syntax { If ( x , y ) → v } True and false then become: { If ( x , y ) → x } { If ( x , y ) → y } With co-paterns: true . If x y = x false . If x y = y We arrive at the familiar encodings in the polymorphic λ -calculus: Bool = ∀ a . a → a → a true = Λ a .λ x : a .λ y : a . x false = Λ a .λ x : a .λ y : a . y The same applies to other data types - Visitor Patern

Declaring functions as co-data codata a → b where call : a → b , a ⊢ b Consumer: one destructor (function call) Argument What to do with result v · e ( v 1 . call ) v Producer: consider shape of the observation µ ( x · α ) . c λ x . v = µ ( x · α ) . � v | | α �

Control solves a dilemma Extensionality is essential for observational properties about program M : A → B M = λ x . M x

Control solves a dilemma Extensionality is essential for observational properties about program M : A → B M = λ x . M x Evaluation to weak-head normal (i.e. a lambda) form avoids renaming

Control solves a dilemma Extensionality is essential for observational properties about program M : A → B M = λ x . M x Evaluation to weak-head normal (i.e. a lambda) form avoids renaming Extensionality and weak reduction are inconsistent in call-by-name: λ x . Ω x = Ω Ω loops forever while λ x . Ω x is done.

Control solves a dilemma Extensionality is essential for observational properties about program M : A → B M = λ x . M x Evaluation to weak-head normal (i.e. a lambda) form avoids renaming Extensionality and weak reduction are inconsistent in call-by-name: λ x . Ω x = Ω Ω loops forever while λ x . Ω x is done. Plotkin call-by-name continuation-passing style transformation (CPS) does not validates the η axiom: [ [ M ] ] [ [ λ x . M x ] ] = λ k . k ( λ x .λ q . [ [ M ] ] ( λ v . v x q ))

Control solves a dilemma Extensionality is essential for observational properties about program M : A → B M = λ x . M x Evaluation to weak-head normal (i.e. a lambda) form avoids renaming Extensionality and weak reduction are inconsistent in call-by-name: λ x . Ω x = Ω Ω loops forever while λ x . Ω x is done. Plotkin call-by-name continuation-passing style transformation (CPS) does not validates the η axiom: [ [ M ] ] [ [ λ x . M x ] ] = λ k . k ( λ x .λ q . [ [ M ] ] ( λ v . v x q )) Thielecke proves that η follows from parametricity Hoffman and Streicher have proposed an alternative CPS based on pairs [ [ λ x . M x ] ] = λ ( x , k ) . [ [ M x ] ] k = λ ( x , k ) . [ [ M ] ] ( x , k ) = [ [ M ] ]

Functions pattern match on the calling context A function is not constructed, it is a destructor of the calling context λ x . M � µ [ x · α ] . � M | | α � Recall let ( x , y ) = v in v ′ = let z = vinv ′ [ π 1 ( z ) / x , π 2 ( z ) / y ] So... � µ ( x · α ) . c | | E � = c [ car E / x , cdr E /α ] We then have: � λ x . Ω x µ [ x · α ] . � Ω | | x · α � patern matching as projections µ [ β ] . � Ω | | car β · cdr β � call stack is surjective µ [ β ] . � Ω | | β � Ω

A continuation is a data structure The continuation is a data structure not a function. [ [ M N ] ] = λ k . [ [ M ] ] λ f . f [ [ N ] ] k [ [ λ x . M ] ] = λ k . k ( λ x . [ [ M ] ])

A continuation is a data structure The continuation is a data structure not a function. [ [ M N ] ] = λ k . [ [ M ] ] λ f . f [ [ N ] ] k [ [ M N ] ] = λ k . [ [ M ] ] ([ [ N ] ] , k ) [ [ λ x . M ] ] = λ k . k ( λ x . [ [ M ] ]) [ [ λ x . M ] ] = λ ( x , k ) . [ [ M ] ] k The same solution restores confluence to λ -calculi with control λ x . ( A bort 0 ) x A bort 0 λ x . A bort 0

Sequent calculus inspired a new intermediate language

Sharing of code - Join Points x > 100 if x > 100 : print "x is large" yes no else : print "x␣ is ␣ large " print "x␣ is ␣small" print "x is small" print "goodbye" print "goodbye" Join Point: A common point where several branches of control flow join together ( φ node in SSA)

Sharing of code - Join Points x > 100 if x > 100 : print "x is large" yes no else : print "x␣ is ␣ large " print "x␣ is ␣small" print "x is small" print "goodbye" print "goodbye" Join Point: A common point where several branches of control flow join together ( φ node in SSA) Disadvantage of continuation-passing style: bakes in the evaluation strategy Join points are very special functions:

Sharing of code - Join Points x > 100 if x > 100 : print "x is large" yes no else : print "x␣ is ␣ large " print "x␣ is ␣small" print "x is small" print "goodbye" print "goodbye" Join Point: A common point where several branches of control flow join together ( φ node in SSA) Disadvantage of continuation-passing style: bakes in the evaluation strategy Join points are very special functions: a) Always tail-called, don’t return b) Never escape their scope Different operational reading: just a jump to a labeled block of code Join points are more efficient to implement, less costly than a full closure

Case-of-Case and Friends In Core: let j x y = big in not ( case z of A x y → j x y → False ) B ⇓ let j x y = big in case z of A x y → not ( j x y ) → not False B This is bad! The join point is ruined ( j no longer tail-called)

Case-of-Case and Friends In Core with join points: let j x y = big in not ( case z of A x y → j x y → False ) B ⇓ let j x y = not big in case z of A x y → j x y → not False B This is much beter! The join point is preserved!

Core with join points The current intermediate language of Haskell has join points ( F J ) F J is still in correspondence with minimal logic; it doesn’t have control Join points are preserved through optimizations We replace Flanagan et al. moto: Think in CPS, work in direct style with Think in sequent calculus, work in direct style.

Recursion and Corecursion In recursion, data is constructed and the consumer is a process that uses the data Data is finite and its use is (potentially) infinite Recursion uses the data, rather than producing it Recursion starts big, and reduces down to a base case

Recursion and Corecursion In recursion, data is constructed and the consumer is a process that uses the data Data is finite and its use is (potentially) infinite Recursion uses the data, rather than producing it Recursion starts big, and reduces down to a base case In corecursion, the use of data is constructed and the producer is a process that generates the data The use of data is finite and its creation is (potentially) infinite Corecursion produces the data, rather than using it Corecursion starts from a seed and produces bigger and bigger internal state