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

1

Input/Output

2

Iteration and Recursion

3

Glasgow Haskell Compiler

4

Summary

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

1

Input/Output The Functional Mindset The IO type The do notation

2

Iteration and Recursion

3

Glasgow Haskell Compiler

4

Summary

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

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

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

Input/Output The IO type

Outline

1

Input/Output The Functional Mindset The IO type The do notation

2

Iteration and Recursion

3

Glasgow Haskell Compiler

4

Summary

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 12 / 44

Input/Output The IO type

The IO type

For every type a there is an IO a type

getString :: IO String getChar :: IO Char

An object of type IO a

1

contains an object of type a

2

wrapped with IO instructions

The wrapping is part of the syntactic sugar

there is no global state what looks like state information is hidden in the wrapping

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 13 / 44

Input/Output The IO type

The IO type

For every type a there is an IO a type

getString :: IO String getChar :: IO Char

An object of type IO a

1

contains an object of type a

2

wrapped with IO instructions

The wrapping is part of the syntactic sugar

there is no global state what looks like state information is hidden in the wrapping

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 13 / 44

Input/Output The IO type

The IO type

For every type a there is an IO a type

getString :: IO String getChar :: IO Char

An object of type IO a

1

contains an object of type a

2

wrapped with IO instructions

The wrapping is part of the syntactic sugar

there is no global state what looks like state information is hidden in the wrapping

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 13 / 44

Input/Output The IO type

IO programs

An object of type IO a is a program

1

a sequence of Input/Output actions

2

a return value of type a

Actions are executed only when the value (a) is needed

if the value is not used, they are never executed Haskell is lazy

do only what actually affects the final output

The return value (of type a)

cannot be accessed by non-IO functions

• nly functions returning IO can unwrap an IO object

Reason: the IO wrapping must be passed on

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 14 / 44

Input/Output The IO type

IO programs

An object of type IO a is a program

1

a sequence of Input/Output actions

2

a return value of type a

Actions are executed only when the value (a) is needed

if the value is not used, they are never executed Haskell is lazy

do only what actually affects the final output

The return value (of type a)

cannot be accessed by non-IO functions

• nly functions returning IO can unwrap an IO object

Reason: the IO wrapping must be passed on

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 14 / 44

Input/Output The IO type

IO programs

An object of type IO a is a program

1

a sequence of Input/Output actions

2

a return value of type a

Actions are executed only when the value (a) is needed

if the value is not used, they are never executed Haskell is lazy

do only what actually affects the final output

The return value (of type a)

cannot be accessed by non-IO functions

• nly functions returning IO can unwrap an IO object

Reason: the IO wrapping must be passed on

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 14 / 44

Input/Output The IO type

IO programs

An object of type IO a is a program

1

a sequence of Input/Output actions

2

a return value of type a

Actions are executed only when the value (a) is needed

if the value is not used, they are never executed Haskell is lazy

do only what actually affects the final output

The return value (of type a)

cannot be accessed by non-IO functions

• nly functions returning IO can unwrap an IO object

Reason: the IO wrapping must be passed on

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 14 / 44

Input/Output The IO type

Combining IO functions and non-IO functions

non-IO functions (returning a non-IO object)

cannot use IO objects the type specifies output independent of any IO

IO input and non-IO output

makes little sense the IO information would be discarded IO input would not be used

IO functions (i.e. functions with IO output)

can sequence other IO objects use the return value of the IO objects use non-IO functions for calculations

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 15 / 44

Input/Output The IO type

Combining IO functions and non-IO functions

non-IO functions (returning a non-IO object)

cannot use IO objects the type specifies output independent of any IO

IO input and non-IO output

makes little sense the IO information would be discarded IO input would not be used

IO functions (i.e. functions with IO output)

can sequence other IO objects use the return value of the IO objects use non-IO functions for calculations

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 15 / 44

Input/Output The IO type

Combining IO functions and non-IO functions

non-IO functions (returning a non-IO object)

cannot use IO objects the type specifies output independent of any IO

IO input and non-IO output

makes little sense the IO information would be discarded IO input would not be used

IO functions (i.e. functions with IO output)

can sequence other IO objects use the return value of the IO objects use non-IO functions for calculations

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 15 / 44

Input/Output The IO type

The one element type

The () type contains one and only one element () When is this useful? When no return value is useful

C and Java have void functions – similar

It makes sense for IO programs

• utput routines are often of type IO ()

non-IO functions with no output would have no effect at all

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 16 / 44

Input/Output The IO type

The one element type

The () type contains one and only one element () When is this useful? When no return value is useful

C and Java have void functions – similar

It makes sense for IO programs

• utput routines are often of type IO ()

non-IO functions with no output would have no effect at all

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 16 / 44

Input/Output The IO type

The one element type

The () type contains one and only one element () When is this useful? When no return value is useful

C and Java have void functions – similar

It makes sense for IO programs

• utput routines are often of type IO ()

non-IO functions with no output would have no effect at all

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 16 / 44

Input/Output The IO type

String output

Main output routine: putStr :: String -> IO ()

recall that it could interpret the special characters e.g. putStr "7\t1567\n8\t166\n"

To print a line (including a newline)

putStrLn :: String -> IO () putStrLn = putStr . (++ "\n")

Printing values in general

print :: Show a => a -> IO () print = putStrLn . show

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 17 / 44

Input/Output The do notation

Outline

1

Input/Output The Functional Mindset The IO type The do notation

2

Iteration and Recursion

3

Glasgow Haskell Compiler

4

Summary

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 18 / 44

Input/Output The do notation

The do notation

IO programs can be sequenced

to execute IO actions in a particular order

We use the do construct

sequences all the IO actions and produce a new IO object

iotest :: IO () iotest = do s <- getLine putStr s putStr "\n" Looks like an imperative program, does it not?

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 19 / 44

Input/Output The do notation

The do notation

IO programs can be sequenced

to execute IO actions in a particular order

We use the do construct

sequences all the IO actions and produce a new IO object

iotest :: IO () iotest = do s <- getLine putStr s putStr "\n" Looks like an imperative program, does it not?

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 19 / 44

Input/Output The do notation

The do notation

IO programs can be sequenced

to execute IO actions in a particular order

We use the do construct

sequences all the IO actions and produce a new IO object

iotest :: IO () iotest = do s <- getLine putStr s putStr "\n" Looks like an imperative program, does it not?

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 19 / 44

Input/Output The do notation

The do notation

IO programs can be sequenced

to execute IO actions in a particular order

We use the do construct

sequences all the IO actions and produce a new IO object

iotest :: IO () iotest = do s <- getLine putStr s putStr "\n" Looks like an imperative program, does it not?

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 19 / 44

Input/Output The do notation

Example explained

1

iotest = do The do construct allows sequencing multiple IO programs, for execution in order.

2

s <- getLine getLine :: IO String reads a line from the terminal. The <- assignment captures just the String from the IO object.

3

putStr s putStr :: String -> IO () prints the string on the terminal.

4

putStr "\n" Print a newline character. The output of iotest is a new IO object, doing all the actions of the three constituent IO objects, and returning void.

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 20 / 44

Input/Output The do notation

Example with differences

iDiff :: IO () iDiff = do line <- getLine let a = ( read line :: Int ) line <- getLine let b = ( read line :: Int ) ( putStr . show ) ( a - b ) let allows local definitions

with non-IO objects

The <- assignment is special:

unwraps an IO object (let does not)

do sequences the IO actions.

first line typed becomes a second line typed becomes b

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 21 / 44

Input/Output The do notation

Example with differences

iDiff :: IO () iDiff = do line <- getLine let a = ( read line :: Int ) line <- getLine let b = ( read line :: Int ) ( putStr . show ) ( a - b ) let allows local definitions

with non-IO objects

The <- assignment is special:

unwraps an IO object (let does not)

do sequences the IO actions.

first line typed becomes a second line typed becomes b

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 21 / 44

Input/Output The do notation

Example with differences

iDiff :: IO () iDiff = do line <- getLine let a = ( read line :: Int ) line <- getLine let b = ( read line :: Int ) ( putStr . show ) ( a - b ) let allows local definitions

with non-IO objects

The <- assignment is special:

unwraps an IO object (let does not)

do sequences the IO actions.

first line typed becomes a second line typed becomes b

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 21 / 44

Input/Output The do notation

Variable assignments

Two types of local variable assignments in a do block

let – regular assignment <- – unwraps an IO object – assigns the return value

Both are local variables, used only inside the do block let is a straight forward local definition

let b = ( read line :: Int ) Defines a short-hand for the right-hand expression

line <- getString captures the String from an IO String

line :: String (not IO String)

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 22 / 44

Input/Output The do notation

Variable assignments

Two types of local variable assignments in a do block

let – regular assignment <- – unwraps an IO object – assigns the return value

Both are local variables, used only inside the do block let is a straight forward local definition

let b = ( read line :: Int ) Defines a short-hand for the right-hand expression

line <- getString captures the String from an IO String

line :: String (not IO String)

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 22 / 44

Input/Output The do notation

Variable assignments

Two types of local variable assignments in a do block

let – regular assignment <- – unwraps an IO object – assigns the return value

Both are local variables, used only inside the do block let is a straight forward local definition

let b = ( read line :: Int ) Defines a short-hand for the right-hand expression

line <- getString captures the String from an IO String

line :: String (not IO String)

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 22 / 44

Input/Output The do notation

Variable assignments

Two types of local variable assignments in a do block

let – regular assignment <- – unwraps an IO object – assigns the return value

Both are local variables, used only inside the do block let is a straight forward local definition

let b = ( read line :: Int ) Defines a short-hand for the right-hand expression

line <- getString captures the String from an IO String

line :: String (not IO String)

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 22 / 44

Input/Output The do notation

Parsing Strings

The read function

read line :: Int parses the String to return an integer

This is a regular, non-IO operation

Observe the use of ::. Why do we give the type? read is overloaded for various output types

and b has not been declared previously declaring the output type resolves the ambiguity of overloading

When defining a declared variable, this would be superfluous

myVar :: Int myVar = read line here the type of myVar resolves the ambiguity

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 23 / 44

Input/Output The do notation

Parsing Strings

The read function

read line :: Int parses the String to return an integer

This is a regular, non-IO operation

Observe the use of ::. Why do we give the type? read is overloaded for various output types

and b has not been declared previously declaring the output type resolves the ambiguity of overloading

When defining a declared variable, this would be superfluous

myVar :: Int myVar = read line here the type of myVar resolves the ambiguity

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 23 / 44

Input/Output The do notation

Parsing Strings

The read function

read line :: Int parses the String to return an integer

This is a regular, non-IO operation

Observe the use of ::. Why do we give the type? read is overloaded for various output types

and b has not been declared previously declaring the output type resolves the ambiguity of overloading

When defining a declared variable, this would be superfluous

myVar :: Int myVar = read line here the type of myVar resolves the ambiguity

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 23 / 44

Input/Output The do notation

Parsing Strings

The read function

read line :: Int parses the String to return an integer

This is a regular, non-IO operation

Observe the use of ::. Why do we give the type? read is overloaded for various output types

and b has not been declared previously declaring the output type resolves the ambiguity of overloading

When defining a declared variable, this would be superfluous

myVar :: Int myVar = read line here the type of myVar resolves the ambiguity

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 23 / 44

Iteration and Recursion

Outline

1

Input/Output

2

Iteration and Recursion

3

Glasgow Haskell Compiler

4

Summary

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 24 / 44

Iteration and Recursion

Iteration

Loops is one of the most important concepts in your Java module

Haskell has no such thing so, how do we write repetition in Haskell?

The answer is Recursion

any loop can be rewritten as a recursion

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 25 / 44

Iteration and Recursion

Iteration

Loops is one of the most important concepts in your Java module

Haskell has no such thing so, how do we write repetition in Haskell?

The answer is Recursion

any loop can be rewritten as a recursion

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 25 / 44

Iteration and Recursion

Recursive while loop

while :: IO Bool -> IO () -> IO () while test action = do res <- test if res then do action while test action else return ()

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 26 / 44

Iteration and Recursion

Important points

Recursive while loop

test argument of type IO Bool

can be sequenced – different value at different times

Base case: test == False

do nothing return :: a -> IO a creates an IO object from another

• bject

Recursive case: test == True

1

Evaluate action

2

Recur – calling while

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 27 / 44

Iteration and Recursion

Copy input to output

an example

copyInputToOutput :: IO () copyInputToOutput = while -- Check for End of File ( do res <- isEOF return (not res))

• - Read and Print line

( do line <- getLine putStrLn line )

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 28 / 44

Iteration and Recursion

An important example

where imperative thinking fails

goUntilEmpty :: IO () goUntilEmpty = do line <- getLine while (return (line /= [])) (do putStrLn line line <- getLine return ()) Each <- assigments creates a new variable

the first line is used for every test the function will print the first line for ever

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 29 / 44

Iteration and Recursion

An important example

where imperative thinking fails

goUntilEmpty :: IO () goUntilEmpty = do line <- getLine while (return (line /= [])) (do putStrLn line line <- getLine return ()) Each <- assigments creates a new variable

the first line is used for every test the function will print the first line for ever

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 29 / 44

Iteration and Recursion

Recursive solution

An important example

Think recursively at all times goUntilEmpty :: IO () goUntilEmpty = do line <- getLine if (line = []) then return () else (do putStrLn line goUntilEmpty)

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 30 / 44

Glasgow Haskell Compiler A self-contained Haskell program

Outline

1

Input/Output

2

Iteration and Recursion

3

Glasgow Haskell Compiler A self-contained Haskell program Compiling Haskell

4

Summary

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 31 / 44

Glasgow Haskell Compiler A self-contained Haskell program

We have yet not seen a Haskell program

We have been playing around with functions Very useful for

testing ideas and learning debugging functions and modules

Difficult for a third-party user

which expression should he type

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 32 / 44

Glasgow Haskell Compiler A self-contained Haskell program

A stand-alone program

A standalone program defines

the module Main an expression main (of some IO type)

When the program is run,

main is evaluated

runhugs filename runs the script

you get no interactive prompt

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 33 / 44

Glasgow Haskell Compiler A self-contained Haskell program

Hello world!

runhugs hello.hs module Main where main = putStr "Hello, World\n"

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 34 / 44

Glasgow Haskell Compiler A self-contained Haskell program

Literal scripts

Normal Haskell files are mainly code

comments are specially marked with - extension .hs

Literal Haskell scripts are mainly comments

code is specially marked with > extension .lhs

This is the basic Hello world programme > module Main where > main = putStr "Hello, World\n" runhugs hello.lhs

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 35 / 44

Glasgow Haskell Compiler A self-contained Haskell program

Literal scripts

Normal Haskell files are mainly code

comments are specially marked with - extension .hs

Literal Haskell scripts are mainly comments

code is specially marked with > extension .lhs

This is the basic Hello world programme > module Main where > main = putStr "Hello, World\n" runhugs hello.lhs

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 35 / 44

Glasgow Haskell Compiler A self-contained Haskell program

Executable scripts

Executable scripts is a general Unix feature The first line indicates the interpreter to use

#! /usr/bin/runhugs +l The rest of the file is code for the interpreter

#! are magic bytes – telling the OS that it is an executable script

should be ignored by the interpreter

# indicates a comment in many languages

not in Haskell though but it is fine in a literal script

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 36 / 44

Glasgow Haskell Compiler A self-contained Haskell program

Hello world!

./hello \#! /usr/bin/runhugs +l > module Main where > main = putStr "Hello, World\n" +l tells hugs that the script is literal

regardless of the filename extension

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 37 / 44

Glasgow Haskell Compiler Compiling Haskell

Outline

1

Input/Output

2

Iteration and Recursion

3

Glasgow Haskell Compiler A self-contained Haskell program Compiling Haskell

4

Summary

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 38 / 44

Glasgow Haskell Compiler Compiling Haskell

Compilers and Interpreters

A compiler translates a program

to machine code to be run on the CPU Java byte code to be run in a virtual machine

An interpreter reads and executes the program on the fly

directly from the human-readable code

A Haskell compiler is provided

ghc

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 39 / 44

Glasgow Haskell Compiler Compiling Haskell

The Glasgow Haskell Compiler (ghc)

georg@nyquist:119> ls -l total 4

• rwxr-xr-x 1 georg georg 76 2008-10-03 16:14 hello.lhs*

georg@nyquist:120> cat hello.lhs #!/usr/bin/runhugs +l > module Main where > main = putStr "Hello World!\n" georg@nyquist:121> ghc hello.lhs georg@nyquist:122> ls -l total 376

• rwxr-xr-x 1 georg georg 367554 2008-10-03 16:14 a.out*
• rw-r--r-- 1 georg georg

206 2008-10-03 16:14 hello.hi

• rwxr-xr-x 1 georg georg

76 2008-10-03 16:14 hello.lhs*

• rw-r--r-- 1 georg georg

2284 2008-10-03 16:14 hello.o georg@nyquist:123> ./a.out Hello World!

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 40 / 44

Glasgow Haskell Compiler Compiling Haskell

Other features in ghc

Choose name for the executable

ghc -o hello hello.lhs

ghci can be run as an interactive interpreter

an alternative to hugs

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 41 / 44

Summary

Outline

1

Input/Output

2

Iteration and Recursion

3

Glasgow Haskell Compiler

4

Summary

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 42 / 44

Summary

Separation of IO

Haskell design limits the use of I/O

regular Haskell functions cannot do I/O I/O functions cannot be used in regular functions

Is this good or bad? Separation is good practice

calculations (regular functions) input/output (interaction with the user)

Recommended in any language Fascilitates reuse of function

you will often want the same calculations in a different application very rarely you will want the same I/O e.g. command-line and GUI front-end for the same back-end

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 43 / 44

Summary

Separation of IO

Haskell design limits the use of I/O

regular Haskell functions cannot do I/O I/O functions cannot be used in regular functions

Is this good or bad? Separation is good practice

calculations (regular functions) input/output (interaction with the user)

Recommended in any language Fascilitates reuse of function

you will often want the same calculations in a different application very rarely you will want the same I/O e.g. command-line and GUI front-end for the same back-end

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 43 / 44

Summary

Separation of IO

Haskell design limits the use of I/O

regular Haskell functions cannot do I/O I/O functions cannot be used in regular functions

Is this good or bad? Separation is good practice

calculations (regular functions) input/output (interaction with the user)

Recommended in any language Fascilitates reuse of function

you will often want the same calculations in a different application very rarely you will want the same I/O e.g. command-line and GUI front-end for the same back-end

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 43 / 44

Summary

Summary

The IO types and the do constructs

allow explicit sequencing of commands (a concept of time) mechanisms for input and output

do constructs look like imperative programs

but are indeed purely functional constructs based on monads it is syntactic sugar some differences still require functional thinking

A stand-alone Haskell program requires a Main module and main expression Stand-alone programs can be

compiled with ghc run as executable scripts with runhugs

Dr Hans Georg Schaathun Input-Output Spring 2010 – Week 8 44 / 44