301AA - Advanced Programming

Similar documents
301AA - Advanced Programming [AP-2017]

301AA - Advanced Programming [AP-2017]

Chapter 5: The Untyped Lambda Calculus

Principles of Programming Languages

Principles of Programming Languages

Introduction to Lambda Calculus. Lecture 7 CS /08/09

Introduction to Lambda Calculus. Lecture 5 CS 565 1/24/08

Lecture 9: More Lambda Calculus / Types

- M ::= v (M M) λv. M - Impure versions add constants, but not necessary! - Turing-complete. - true = λ u. λ v. u. - false = λ u. λ v.

Type Systems Winter Semester 2006

λ calculus Function application Untyped λ-calculus - Basic Idea Terms, Variables, Syntax β reduction Advanced Formal Methods

Lambda Calculus. Lecture 4 CS /26/10

Formal Semantics. Aspects to formalize. Lambda calculus. Approach

CS152: Programming Languages. Lecture 7 Lambda Calculus. Dan Grossman Spring 2011

CIS 500 Software Foundations Fall September 25

COMP 1130 Lambda Calculus. based on slides by Jeff Foster, U Maryland

Functional Programming and λ Calculus. Amey Karkare Dept of CSE, IIT Kanpur

11/6/17. Outline. FP Foundations, Scheme. Imperative Languages. Functional Programming. Mathematical Foundations. Mathematical Foundations

CSE 505: Concepts of Programming Languages

Last class. CS Principles of Programming Languages. Introduction. Outline

Lecture 5: The Untyped λ-calculus

Functional Programming

Functional Languages and Higher-Order Functions

lambda calculus History 11/28/13 Jianguo Lu A formal system designed to inves:gate func:on defini:on, func:on applica:on, and recursion.

Lambda Calculus. Adrian Groza. Department of Computer Science Technical University of Cluj-Napoca

CS 4110 Programming Languages & Logics. Lecture 17 Programming in the λ-calculus

Whereweare. CS-XXX: Graduate Programming Languages. Lecture 7 Lambda Calculus. Adding data structures. Data + Code. What about functions

Graphical Untyped Lambda Calculus Interactive Interpreter

The Lambda Calculus. 27 September. Fall Software Foundations CIS 500. The lambda-calculus. Announcements

Lambda Calculus. Lambda Calculus

CIS 500 Software Foundations Midterm I

The Untyped Lambda Calculus

5. Introduction to the Lambda Calculus. Oscar Nierstrasz

Recursive Definitions, Fixed Points and the Combinator

Recursion. Lecture 6: More Lambda Calculus Programming. Fixed Points. Recursion

The Untyped Lambda Calculus

Imperative languages

Functional Programming. Overview. Topics. Recall λ-terms. Examples

Lambda Calculus-2. Church Rosser Property

M. Snyder, George Mason University LAMBDA CALCULUS. (untyped)

More Lambda Calculus and Intro to Type Systems

9/23/2014. Why study? Lambda calculus. Church Rosser theorem Completeness of Lambda Calculus: Turing Complete

CITS3211 FUNCTIONAL PROGRAMMING

λ-calculus Lecture 1 Venanzio Capretta MGS Nottingham

1 Scope, Bound and Free Occurrences, Closed Terms

Concepts of programming languages

Fundamentals and lambda calculus

Overview. A normal-order language. Strictness. Recursion. Infinite data structures. Direct denotational semantics. Transition semantics

Pure Lambda Calculus. Lecture 17

Introduction to the Lambda Calculus

The Untyped Lambda Calculus

Advanced Topics in Programming Languages Lecture 3 - Models of Computation

CMSC 330: Organization of Programming Languages. Lambda Calculus

n n Try tutorial on front page to get started! n spring13/ n Stack Overflow!

Computer Science 203 Programming Languages Fall Lecture 10. Bindings, Procedures, Functions, Functional Programming, and the Lambda Calculus

Programming Languages Lecture 14: Sum, Product, Recursive Types

Programming Language Features. CMSC 330: Organization of Programming Languages. Turing Completeness. Turing Machine.

CMSC 330: Organization of Programming Languages

dynamically typed dynamically scoped

Programming Languages

Programming Languages Lecture 15: Recursive Types & Subtyping

CS 11 Haskell track: lecture 1

Denotational Semantics. Domain Theory

One of a number of approaches to a mathematical challenge at the time (1930): Constructibility

CMSC 330: Organization of Programming Languages

Haskell An Introduction

CMSC 330: Organization of Programming Languages. Lambda Calculus

Lecture 5: Lazy Evaluation and Infinite Data Structures

Lecture Notes on Data Representation

Programming Languages. Programming with λ-calculus. Lecture 11: Type Systems. Special Hour to discuss HW? if-then-else int

The Untyped Lambda Calculus

Pure (Untyped) λ-calculus. Andrey Kruglyak, 2010

CSCE 314 TAMU Fall CSCE 314: Programming Languages Dr. Flemming Andersen. Haskell Functions

Resources: The slides of this lecture were derived from [Järvi], with permission of the original author, by copy & x = 1 let x = 1 in...

CMSC 330: Organization of Programming Languages

Introduction to the Lambda Calculus. Chris Lomont

Fundamentals and lambda calculus. Deian Stefan (adopted from my & Edward Yang s CSE242 slides)

Principles of Programming Languages

Elixir, functional programming and the Lambda calculus.

More Lambda Calculus and Intro to Type Systems

Lambda Calculus. Variables and Functions. cs3723 1

Introduction to the λ-calculus

Part I. Historical Origins

INF 212 ANALYSIS OF PROG. LANGS LAMBDA CALCULUS. Instructors: Crista Lopes Copyright Instructors.

Lambda Calculus and Extensions as Foundation of Functional Programming

Lecture #3: Lambda Calculus. Last modified: Sat Mar 25 04:05: CS198: Extra Lecture #3 1

Haskell: Lists. CS F331 Programming Languages CSCE A331 Programming Language Concepts Lecture Slides Friday, February 24, Glenn G.

CSE 505. Lecture #9. October 1, Lambda Calculus. Recursion and Fixed-points. Typed Lambda Calculi. Least Fixed Point

Getting Started with Haskell (10 points)

Untyped Lambda Calculus

Lambda Calculus. CS 550 Programming Languages Jeremy Johnson

Constraint-based Analysis. Harry Xu CS 253/INF 212 Spring 2013

Costly software bugs that could have been averted with type checking

Functional Programming

Haske k ll An introduction to Functional functional programming using Haskell Purely Lazy Example: QuickSort in Java Example: QuickSort in Haskell

CSE-321 Programming Languages 2010 Midterm

Foundations. Yu Zhang. Acknowledgement: modified from Stanford CS242

CITS3211 FUNCTIONAL PROGRAMMING. 14. Graph reduction

Chapter 11 :: Functional Languages

Parsing. Zhenjiang Hu. May 31, June 7, June 14, All Right Reserved. National Institute of Informatics

Transcription:

301AA - Advanced Programming Lecturer: Andrea Corradini andrea@di.unipi.it h;p://pages.di.unipi.it/corradini/ Course pages: h;p://pages.di.unipi.it/corradini/dida@ca/ap-18/ AP-2018-18: Lambda Calculus, Haskell, Call by need

Summary Lambda Calculus Parameter passing mechanisms Call by sharing Call by name Call by need More on Haskell 2

λ-calculus: syntax λ-terms: t ::= x λx.t t t (t) x variable, name, symbol, λx.t abstrac:on, defines an anonymous funcron t t' applica:on of funcron t to argument t Terms can be represented as abstract syntax trees SyntacRc ConvenRons ApplicaRons associates to let t 1 t 2 t 3 (t 1 t 2 ) t 3 The body of abstracron extends as far as possible λx. λy. x y x λx. (λy. (x y) x) A simple tutorial on lambda calculus: http://www.inf.fu-berlin.de/lehre/ws03/alpi/lambda.pdf! 3

Free vs. Bound Variables An occurrence of x is free in a term t if it is not in the body of an abstracron λx. t otherwise it is bound λx is a binder Examples λz. λx. λy. x (y z) (λx. x) x Terms without free variables are combinators IdenRty funcron: id = λx. x First projecron: fst = λx. λy. x

OperaRonal SemanRcs [β-reducron] func:on applica:on redex (λx.t) t' = t [t'/x] (λ x. x) y (λ x. x (λ x. x) ) (u r) y u r (λ x.x) (λ x. (λw. x w)) (y z) λw. y z w (λ x. x x)(λx. x x) (λx. x x) (λx. x x) Other relevant concepts: Normal Forms, α-conversion, η-reducron

λ-calculus as a funcronal language Despite the simplicity, we can encode in λ- calculus most concepts of funcronal languages: FuncRons with several arguments Booleans and logical connecrves Integers and operarons on them Pairs and tuples Recursion 6

FuncRons with several arguments A definiron of a funcron with a single argument associates a name with a λ-abstracron f x = <exp> f = λx.<exp> -- is equivalent to A funcron with several argument is equivalent to a sequence of λ-abstracrons f(x,y) = <exp> -- is equivalent to f = λx.λy.<exp> Currying and Uncurrying curry :: ((a, b) -> c) -> a -> b -> c curry f x y = f(x,y) uncurry :: (a -> b -> c) -> (a, b) -> c uncurry f (x,y) = f x y

Church Booleans T = λt.λf.t -- first! F = λt.λf.f -- second! and = λb.λc.bcf! or = λb.λc.btc! not = λx.xft! test =λl.λm.λn.lmn! test F u w! à (λl.λm.λn.lmn) F u w! à (λm.λn.fmn) u w! à (λn.fun) w! à Fuw! à w! and T F! à (λb.λc.bcf) T F! à (λc.tcf) F! à TFF! à F! not F! à (λx.xft) F! à FFT! à T!

Pairs pair = λf.λs.λb.b f s! fst = λp.p T! snd = λp.p F! fst (pair u w)! à (λp.p T) (pair u w)! à (pair u w) T! à (λf.λs.λb.b f s) u w T! à (λs.λb.b u s) w T! à (λb.b u w) T! à T u w! à u!

Church Numerals Higher order funcrons: n takes a funcron s as argument 0 = λs. λz. z! and returns the n-th composiron 1 = λs. λz. s z! of s with itself, s n 2 = λs. λz. s (s z)! 3 = λs. λz. s (s (s z))! A first simple funcron: succ = λn. λs. λz. s (n s z)! s n succ 2! à (λn. λs. λz. s (n s z)) 2! à (λs. λz. s (2 s z))! à (λs. λz. s ((λs. λz. s (s z)) s z))! à (λs. λz. s (s (s z)) = 3! applies the funcron one more Rme

ArithmeRcs with Church Numerals AddiRon: plus = λm. λn. λs. λz. m s (n s z)! s m MulRplicaRon:! times = λm. λn. λs. λz. m (n s) z! s n (s n ) m = s n*m ExponenRaRon:! m n pow = λm. λn. λs. λz. n m s z! Test by zero: Z = λx. x F not F! Z 0 = ((0 F) not) F = not F = T! Z n = ((n F) not) F = F n (not) F = F!

Fix-point combinator and recursion The following fix-point combinator Y, when applied to a funcron R, returns a fix-point of R, i.e. R(YR) = YR Y = (λy.(λx.y(x x))(λx.y(x x)))! YR!= (λx.r(x x))(λx.r(x x))!!!= R((λx.R(x x))(λx.r(x x))) = R(YR)! A recursive funcron definiron (like factorial) can be read as a higher-order transformaron having a funcron as first argument, and the desired funcron is its fix-point.!!

Fix-point combinator and recursion A recursive definiron: sums(n) = (n==0? 0 : n + sums(n-1))! sums = \n -> (n == 0? 0 : n + sums(n-1))! sums is the fix-point of the following higher-order funcron:! R = \F -> \n -> (n == 0? 0 : n + F(n-1))! R=(λr.λn.Z n 0 (n S (r (P n)))) // in λ-calculus Example of applicaron! (Y R) 3 = R (Y R) 3 =! (3 == 0? 0 : 3 + (Y R) (3-1)) =!! 3 + (Y R) 2 =! 3 + R (Y R) 2 =! 3 + (2 == 0? 0 : 2 + (Y R) (2-1)) =! 3 + 2 + (Y R) 1 =!... 3 + 2 + 1 + 0 = 6

ApplicaRve and Normal Order evaluaron Applica3ve Order evaluaron Arguments are evaluated before applying the funcron aka Eager evalua:on, parameter passing by value Normal Order evaluaron FuncRon evaluated first, arguments if and when needed Sort of parameter passing by name Some evaluaron can be repeated Church-Rosser If evaluaron terminates, the result (normal form) is unique If some evaluaron terminates, normal order evaluaron terminates β-conversion (λx.t) t = t [t /x] Applica3ve order (λx.(+ x x)) (+ 3 2) à (λx.(+ x x)) 5 à (+ 5 5) à 10 Define Ω = (λx.x x) Then ΩΩ = (λx.x x) (λx.x x) à x x [(λx.x x)/x] à (λx.x x) (λx.x x) = ΩΩ à non-termina:ng (λx. 0) (ΩΩ) à { Applica:ve order} non-termina:ng (λx. 0) (ΩΩ) à { Normal order} 0 Normal order (λx.(+ x x)) (+ 3 2) à (+ (+ 3 2) (+ 3 2)) à (+ 5 (+ 3 2)) à (+ 5 5) 14 à 10

Parameter Passing Mechanisms Parameter passing modes In In/out Out Parameter passing mechanisms Call by value (in) Call by reference (in+out) Call by result (out) Call by value/result (in+out) Call by need (in) Call by sharing (in/out) Call by name (in+out) 15

L-Values vs. R-Values and Value Model vs. Reference Model Consider the assignment of the form: a = b a is an l-value, an expression denorng a loca3on, e.g. an array element a[2] a variable foo a dereferenced pointer *p a more complex expression like (f(a)+3)->b[c] b is an r-value: any syntacrcally valid expression with a type comparble to that of a Languages that adopt the value model of variables copy the value of b into the locaron of a Languages that adopt the reference model of variables copy references, resulrng in shared data values via mulrple references 16

Value Model vs. Reference Model in some programming languages Lisp/Scheme, ML, Haskell, Smalltalk adopt the reference model. They copy the reference of b into a so that a and b refer to the same object Most imperarve programming languages use the value model Java uses the value model for built-in types and the reference model for class instances C# uses value model for value types, reference model for reference types 17

Assignment in Value Model vs. Reference Model a 4 b := 2; c := b; a := b + c Value model b c 2 2 a 4 Reference model b c 2 18

References and pointers Most implementa3ons of PLs have as target architecture a Von Neumann one, where memory is made of cells with addresses Thus implementarons use the value model of the target architecture AssumpRon: every data structure is stored in memory cells We define : A reference to X is the address of the (base) cell where X is stored A pointer to X is a locaron containing the address of X Value model based implementarons can mimic the reference model using pointers and standard assignment Each variable is associated with a locaron To let variable y refer to data X, the address of (reference to) X is wri;en in the locaron of y, which becomes a pointer. 19

Parameter Passing by Sharing Call by sharing: parameter passing of data in the reference model The value of the variable is passed as actual argument, which in fact is a reference to the (shared) data Essentially this is call by value of the variable! Java uses both pass by value and pass by sharing Variables of primitive built-in types are passed by value Class instances are passed by sharing The implementation is identical 20

Parameter Passing in Algol 60 Algol 60 uses call by name by default, but also call by value Effect of call by name is like β-reducron in λ-calculus: the actual parameter is copied wherever the formal parameter appears in the body, then the resulrng code is executed Thus the actual parameter is evaluated a number of Rmes (0, 1, ) that depends on the logic of the program Since the actual parameter can contain names, it is passed in a closure with the environment at invocaron Rme (called a thunk) Call by name is powerful but makes programs difficult to read and to debug (think to λ-calculus ): dismissed in subsequent versions of Algol 21

An example of Call by Name: Jensen s device What does the following Algol 60 procedure compute? real procedure sum(expr, i, low, high); value low, high; low and high are passed by value real expr; expr and i are passed by name integer i, low, high; begin real rtn; rtn := 0; for i := low step 1 until high do rtn := rtn + expr; sum := rtn return value by assigning to function name end sum Apparently, (high-low+1) * expr! 22

An example of Call by Name: Jensen s device But: y := sum(3*x*x-5*x+2,x,1,10) real procedure sum(expr, i, low, high); value low, high; low and high are passed by value real expr; expr and i are passed by name integer i, low, high; begin real rtn; rtn := 0; for x := low step 1 until high do rtn := rtn + 3*x*x-5*x+2; sum := rtn return value by assigning to function name end sum It computes! 10 y = Σ 3x 2-5x+2 x=1 23

Call by name & Lazy evaluaron (call by need) In call by name parameter passing (default in Algol 60) arguments (like expressions) are passed as a closure ( thunk ) to the subrourne The argument is (re)evaluated each Rme it is used in the body Haskell realizes lazy evaluabon by using call by need parameter passing, which is similar: an expression passed as argument is evaluated only if its value is needed. Unlike call by name, the argument is evaluated only the first :me, using memoizabon: the result is saved and further uses of the argument do not need to re-evaluate it 24

Call by name & Lazy evaluaron (call by need) Combined with lazy data constructors, this allows to construct potenrally infinite data structures and to call infinitely recursive funcrons without necessarily causing non-terminaron Note: lazy evaluaron works fine with purely func3onal languages Side effects require that the programmer reasons about the order that things happen, not predictable in lazy languages. We will address this fact when introducing Hakell's IO- Monad 25

Summary of Parameter Passing Modes 26

Back to Haskell 27

Laziness Haskell is a lazy language FuncRons and data constructors (also user-defined ones) don t evaluate their arguments unrl they need them cond True t e = t cond False t e = e cond :: Bool -> a -> a -> a cond True [] [1..] => [] Programmers can write control-flow operators that have to be built-in in eager languages Shortcircuiting ( ) :: Bool -> Bool -> Bool True x = True or False x = x 28

List Comprehensions NotaRon for construcrng new lists from old ones: mydata = [1,2,3,4,5,6,7] twicedata = [2 * x x <- mydata] -- [2,4,6,8,10,12,14] twiceevendata = [2 * x x <- mydata, x `mod` 2 == 0] -- [4,8,12] Similar to set comprehension { x x A x > 6 } 29

More on List Comprehensions ghci> [ x x <- [10..20], x /= 13, x /= 15, x /= 19] [10,11,12,14,16,17,18,20] - more predicates ghci> [ x*y x <- [2,5,10], y <- [8,10,11]] [16,20,22,40,50,55,80,100,110] - more lists length xs = sum [1 _ <- xs] - anonymous (don t care) var - strings are lists removenonuppercase st = [ c c <- st, c `elem` ['A'..'Z']] 30