Input-Output CS190 Functional Programming Techniques Dr Hans Georg - PowerPoint PPT Presentation

Input-Output CS190 Functional Programming Techniques Dr Hans Georg Schaathun University of Surrey Spring 2010 – Week 8 Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 1 / 44

Outline Input/Output 1 Iteration and Recursion 2 Glasgow Haskell Compiler 3 Summary 4 Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 2 / 44

This session After this session, you have an idea of how to write complete programs in Haskell, using Input/Output be able to make standalone executables which can run without using hugs have an improved understanding of the features of pure functional programming Read Thompson Chapter 18 Although I/O will not examined, its study does help the understanding of what pure functional programming which may be examined. Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 3 / 44

Input/Output The Functional Mindset Outline Input/Output 1 The Functional Mindset The IO type The do notation Iteration and Recursion 2 Glasgow Haskell Compiler 3 Summary 4 Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 4 / 44

Input/Output The Functional Mindset The I/O problem Suppose we have a getInt function reading an integer from the terminal Then, define iDiff = getInt - getInt what is the result of this? Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 5 / 44

Input/Output The Functional Mindset Referential Transparency Hypothesis 1 iDiff = getInt - getInt Answer has to be 0. Why? Any given expression always has the same value getInt cannot have two different values, hence the difference is 0 This is called referential transparency fundamental to pure functional programming Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 6 / 44

Input/Output The Functional Mindset Referential Transparency Hypothesis 1 iDiff = getInt - getInt Answer has to be 0. Why? Any given expression always has the same value getInt cannot have two different values, hence the difference is 0 This is called referential transparency fundamental to pure functional programming Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 6 / 44

Input/Output The Functional Mindset Order of Evaluation The C Hypothesis iDiff = getInt - getInt is ambiguous which call is evaluated first? Do you know this? If the user enters first 2, then 4, do you get 2 or − 2? Many programming languages (including C) refuse to answer it is undefined i.e. it is compiler dependent With referential transparency, it does not matter Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 7 / 44

Input/Output The Functional Mindset Order of Evaluation The C Hypothesis iDiff = getInt - getInt is ambiguous which call is evaluated first? Do you know this? If the user enters first 2, then 4, do you get 2 or − 2? Many programming languages (including C) refuse to answer it is undefined i.e. it is compiler dependent With referential transparency, it does not matter Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 7 / 44

Input/Output The Functional Mindset Order of Evaluation The C Hypothesis iDiff = getInt - getInt is ambiguous which call is evaluated first? Do you know this? If the user enters first 2, then 4, do you get 2 or − 2? Many programming languages (including C) refuse to answer it is undefined i.e. it is compiler dependent With referential transparency, it does not matter Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 7 / 44

Input/Output The Functional Mindset Order of Evaluation The C Hypothesis iDiff = getInt - getInt is ambiguous which call is evaluated first? Do you know this? If the user enters first 2, then 4, do you get 2 or − 2? Many programming languages (including C) refuse to answer it is undefined i.e. it is compiler dependent With referential transparency, it does not matter Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 7 / 44

Input/Output The Functional Mindset The Functional Paradigm A pure functional programming (e.g. Haskell) is a list of definitions Time is not an issue An equality = in Haskell states a fact – it just is it does not change Definitions are assumed to be universally valid they don’t change The interpreter reads all the definitions before calculations start definitions can use names defined later Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 8 / 44

Input/Output The Functional Mindset The Functional Paradigm A pure functional programming (e.g. Haskell) is a list of definitions Time is not an issue An equality = in Haskell states a fact – it just is it does not change Definitions are assumed to be universally valid they don’t change The interpreter reads all the definitions before calculations start definitions can use names defined later Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 8 / 44

Input/Output The Functional Mindset The Functional Paradigm A pure functional programming (e.g. Haskell) is a list of definitions Time is not an issue An equality = in Haskell states a fact – it just is it does not change Definitions are assumed to be universally valid they don’t change The interpreter reads all the definitions before calculations start definitions can use names defined later Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 8 / 44

Input/Output The Functional Mindset The Functional Paradigm A pure functional programming (e.g. Haskell) is a list of definitions Time is not an issue An equality = in Haskell states a fact – it just is it does not change Definitions are assumed to be universally valid they don’t change The interpreter reads all the definitions before calculations start definitions can use names defined later Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 8 / 44

Input/Output The Functional Mindset Input/Output and Time Input/Output happens in time Input is received in sequence Output has to be produced in the correct order Interactive applications depends heavily on time calculations depends on input which was not known when the definitions were read Input changes the behaviour of the program Likewise, output will influence the user’s input Without the ordering in time the interactions makes no sense Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 9 / 44

Input/Output The Functional Mindset Input/Output and Time Input/Output happens in time Input is received in sequence Output has to be produced in the correct order Interactive applications depends heavily on time calculations depends on input which was not known when the definitions were read Input changes the behaviour of the program Likewise, output will influence the user’s input Without the ordering in time the interactions makes no sense Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 9 / 44

Input/Output The Functional Mindset Input/Output and Time Input/Output happens in time Input is received in sequence Output has to be produced in the correct order Interactive applications depends heavily on time calculations depends on input which was not known when the definitions were read Input changes the behaviour of the program Likewise, output will influence the user’s input Without the ordering in time the interactions makes no sense Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 9 / 44

Input/Output The Functional Mindset Input/Output and Time Input/Output happens in time Input is received in sequence Output has to be produced in the correct order Interactive applications depends heavily on time calculations depends on input which was not known when the definitions were read Input changes the behaviour of the program Likewise, output will influence the user’s input Without the ordering in time the interactions makes no sense Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 9 / 44

Input/Output The Functional Mindset Input/Output and Time Input/Output happens in time Input is received in sequence Output has to be produced in the correct order Interactive applications depends heavily on time calculations depends on input which was not known when the definitions were read Input changes the behaviour of the program Likewise, output will influence the user’s input Without the ordering in time the interactions makes no sense Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 9 / 44

Input/Output The Functional Mindset Solutions How do we deal with input-output? Cheating Functions with side-effects. imperative behaviour a state is changed Monads Pure functional approach. very abstract mathematical concept details left for another course Syntactic sugar imperative-style syntax expressing Monads the behaviour is functional the programmer can think imperatively Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 10 / 44

Input/Output The Functional Mindset The Haskell Solution Haskell chooses the third approach – syntactic sugar You will see a small imperative program The interpreter sees a pure functional program Known as Syntactic Sugar Advanced concepts are hidden by syntactic simplicity This lecture will explore how to sugar the functional types we have already seen how to use the basic elements of IO notation Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 11 / 44