このページは https://speakerdeck.com/mchakravarty/do-extraterrestrials-use-functional-programming の内容を掲載しています。

掲載を希望されないスライド著者の方は、こちらよりご連絡下さい。

3年以上前 (2013/05/16)にアップロードinテクノロジー

Opening Keynote at YOW! Lambda Jam, Brisbane, 2013.

Is functional programming just the result o...

Opening Keynote at YOW! Lambda Jam, Brisbane, 2013.

Is functional programming just the result of clever language design? Are there deeper reasons for the effectiveness of the paradigm? Why has functional programming not caught on earlier?

In this talk, we will have a look at the roots of functional programming, at their contribution to the success of the paradigm, and at the lessons we can draw to maximise the benefit we derive from functional languages. I will argue that the core of functional programming is a principled approach to software design compatible with both rigorous and agile methods of software development. It stems from a desire for purity, composability, and elegant logical properties, and I will outline how to leverage these ideas to solve practical programming problems.

A video of the talk is available at http://www.youtube.com/watch?v=gUZYHo_nrVU

- Do Extraterrestrials Use Functional Programming?

Manuel M T Chakravarty

University of New South Wales

mchakravarty

α TacticalGrace

TacticalGrace

1

» Straight to next slide

[15min Question (λ); 20min Methodology; 15min Application] - Part 1

The Question

2

This talk will be in three parts.

(1) Discussing essence of functional programming. What makes FP tick?

(2) How do FP principles influence software dev? Will propose a dev methodology for FP.

(3) Look at concrete dev project, where we applied this methodology. »»Let's start with The

Question… - “Do Extraterrestrials Use

Functional Programming?”

3

» <Read question>

* To visit us, they need to be on an advanced technological level with a deep understanding

of science.

* They won't speak one of humanity's languages, though. So, how do we establish a common

basis? - 4

* How to communicate?

* Common idea: universal principles may help establish a basis — universal constants or

universal laws. - 4

* How to communicate?

* Common idea: universal principles may help establish a basis — universal constants or

universal laws. - π?

4

* How to communicate?

* Common idea: universal principles may help establish a basis — universal constants or

universal laws. - E = mc2

π?

4

* How to communicate?

* Common idea: universal principles may help establish a basis — universal constants or

universal laws. - 5

* Computer languages? Agree on a common language of computation?

* In 1936, Alonzo Church introduced the lambda calculus: <Explain lambda calculus>

* Serve as a common language? Like a computational Esperanto?

* Also other calculi/machines. Famous: Turing machines. Which would aliens pick? »» Let's

look: how are they related… - M, N → x | λx.M | M N

Alonzo Church

5

* Computer languages? Agree on a common language of computation?

* In 1936, Alonzo Church introduced the lambda calculus: <Explain lambda calculus>

* Serve as a common language? Like a computational Esperanto?

* Also other calculi/machines. Famous: Turing machines. Which would aliens pick? »» Let's

look: how are they related… - M, N → x | λx.M | M N

Alonzo Church

5

* Computer languages? Agree on a common language of computation?

* In 1936, Alonzo Church introduced the lambda calculus: <Explain lambda calculus>

* Serve as a common language? Like a computational Esperanto?

* Also other calculi/machines. Famous: Turing machines. Which would aliens pick? »» Let's

look: how are they related… - M, N → x | λx.M | M N

Alonzo Church

5

* Computer languages? Agree on a common language of computation?

* In 1936, Alonzo Church introduced the lambda calculus: <Explain lambda calculus>

* Serve as a common language? Like a computational Esperanto?

* Also other calculi/machines. Famous: Turing machines. Which would aliens pick? »» Let's

look: how are they related…

Alonzo Church

5

* Computer languages? Agree on a common language of computation?

* In 1936, Alonzo Church introduced the lambda calculus: <Explain lambda calculus>

* Serve as a common language? Like a computational Esperanto?

* Also other calculi/machines. Famous: Turing machines. Which would aliens pick? »» Let's

look: how are they related…

Alonzo Church

5

* Computer languages? Agree on a common language of computation?

* In 1936, Alonzo Church introduced the lambda calculus: <Explain lambda calculus>

* Serve as a common language? Like a computational Esperanto?

* Also other calculi/machines. Famous: Turing machines. Which would aliens pick? »» Let's

look: how are they related…- M, N → x | λx.M | M N

Alan Turing

Alonzo Church

5

* Computer languages? Agree on a common language of computation?

* In 1936, Alonzo Church introduced the lambda calculus: <Explain lambda calculus>

* Serve as a common language? Like a computational Esperanto?

* Also other calculi/machines. Famous: Turing machines. Which would aliens pick? »» Let's

look: how are they related… - M, N → x | λx.M | M N

Alan Turing

Alonzo Church

6

* The lambda calculus and Turing machines have the same origin.

* Beginning 20th century: group of famous mathematicians interested in formalising

foundation of mathematics.

»» This led to an important question… - Lambda Calculus

Turing Machine

M, N → x | λx.M | M N

6

* The lambda calculus and Turing machines have the same origin.

* Beginning 20th century: group of famous mathematicians interested in formalising

foundation of mathematics.

»» This led to an important question… - Lambda Calculus

Turing Machine

M, N → x | λx.M | M N

By-product of a study of the

foundation and expressive power

of mathematics.

6

* The lambda calculus and Turing machines have the same origin.

* Beginning 20th century: group of famous mathematicians interested in formalising

foundation of mathematics.

»» This led to an important question… - David Hilbert

7

* Challenge posed by David Hilbert, 1928: the Entscheidungsproblem (decision problem)

* Church & Turing, 1936, no solution, using lambda calculus & Turing machines.

»» So what is the Entscheidungsproblem… - Is there a solution to the

David Hilbert

Entscheidungsproblem?

7

* Challenge posed by David Hilbert, 1928: the Entscheidungsproblem (decision problem)

* Church & Turing, 1936, no solution, using lambda calculus & Turing machines.

»» So what is the Entscheidungsproblem… - Is there a solution to the

David Hilbert

Entscheidungsproblem?

No!

No!

7

* Challenge posed by David Hilbert, 1928: the Entscheidungsproblem (decision problem)

* Church & Turing, 1936, no solution, using lambda calculus & Turing machines.

»» So what is the Entscheidungsproblem… - “Is there an algorithm to decide

whether a given statement is

provable from a set of axioms

using the rules of first-order

logic?”

8

* In other words: Given a world & a set of fixed rules in the world, check whether the world

has a particular property.

»» In turn, leads to the question… - “How do you prove that an

algorithm does not exist?”

9

* Because we cannot solve the challenge, doesn't mean it is unsolvable?

* Need systematic way to rigorously prove that a solution is impossible.

»» Church & Turing proceeded as follows… - 10

* 1936, the concept of an algorithm remained to be formally defined - (1) Define a universal language

or abstract machine.

(2) Show that the desired

algorithm cannot be

expressed in the language.

10

* 1936, the concept of an algorithm remained to be formally defined - Define a universal language

or abstract machine.

11

* Two steps <Explain>

* Church & Turing used: (1) lambda term, (2) Turing machine

* Hypothesis: universal — ie, any algorithmically computable function can be expressed

»» They conjectured… - Define a universal language

or abstract machine.

Lambda Calculus

Turing Machine

M, N → x | λx.M | M N

11

* Two steps <Explain>

* Church & Turing used: (1) lambda term, (2) Turing machine

* Hypothesis: universal — ie, any algorithmically computable function can be expressed

»» They conjectured… - Universal language

Lambda Calculus

Turing Machine

M, N → x | λx.M | M N

11

* Two steps <Explain>

* Church & Turing used: (1) lambda term, (2) Turing machine

* Hypothesis: universal — ie, any algorithmically computable function can be expressed

»» They conjectured… - Universal language

Church-Turing thesis

Lambda Calculus

Turing Machine

M, N → x | λx.M | M N

11

* Two steps <Explain>

* Church & Turing used: (1) lambda term, (2) Turing machine

* Hypothesis: universal — ie, any algorithmically computable function can be expressed

»» They conjectured… - Computational Power

Lambda Calculus

Turing Machine

M, N → x | λx.M | M N

=

12

* Any program expressible in one is expressible in the other.

»» However, … - Generality

Lambda Calculus

Turing Machine

M, N → x | λx.M | M N

13

* Lambda calculus: embodies concept of (functional) *abstraction*

* Functional abstraction is only one embodiment of an underlying more general concept.

»» This is important, as… - Generality

Lambda Calculus

Turing Machine

≫

M, N → x | λx.M | M N

13

* Lambda calculus: embodies concept of (functional) *abstraction*

* Functional abstraction is only one embodiment of an underlying more general concept.

»» This is important, as… - “Generality increases if a

discovery is independently

made in a variety of

contexts.”

14

» Read the statement.

* If a concept transcends one application, its generality increases.

»» This is the case for the lambda calculus… - Simply typed

lambda calculus

15

* Firstly, lambda calculus (no polytypes)…

»» Mathematicians Haskell Curry & William Howard discovered: it is structurally equivalent

to… - Lambda calculus with monotypes

Simply typed

lambda calculus

15

* Firstly, lambda calculus (no polytypes)…

»» Mathematicians Haskell Curry & William Howard discovered: it is structurally equivalent

to… - Intuitionistic

propositional logic

16

»» Later, Joachim Lambek found: they correspond to… - Constructive logic

Intuitionistic

propositional logic

16

»» Later, Joachim Lambek found: they correspond to… - Simply typed

Intuitionistic

Cartesian closed

lambda calculus

propositional logic

categories

17

* Three independently discovered artefacts share the same structure!

* Implies an equivalence between programming & proving.

»» The upshot of all this… - Structure from category theory

Simply typed

Intuitionistic

Cartesian closed

lambda calculus

propositional logic

categories

17

* Three independently discovered artefacts share the same structure!

* Implies an equivalence between programming & proving.

»» The upshot of all this… - Simply typed

lambda calculus

Curry-Howard-Lambek correspondence

Intuitionistic

Cartesian closed

propositional logic

categories

17

* Three independently discovered artefacts share the same structure!

* Implies an equivalence between programming & proving.

»» The upshot of all this… - “Alonzo Church didn't invent

the lambda calulus;

he discovered it.”

18

» Read the statement.

* Just like Issac Newton didn't invent the Law of Gravity, but discovered it.

»» Getting back to our extraterrestrials… - 19

* Lambda calculus: fundamental, inevitable, universal notion of computation.

* In all likelihood: extraterrestials know about it, like they will know π. - 19

* Lambda calculus: fundamental, inevitable, universal notion of computation.

* In all likelihood: extraterrestials know about it, like they will know π. - M, N → x | λx.M | M N

M, N → x | λx.M | M N

19

* Lambda calculus: fundamental, inevitable, universal notion of computation.

* In all likelihood: extraterrestials know about it, like they will know π. - “So what?”

20

* Is all this simply a academic curiosity?

* Does it impact the practical use of FLs?

»» It is crucial for FLs… - 21

* FLs: pragmatic renderings of lambda calculus with syntactic sugar etc for convenience.

* Important application: compilation via extended lambda calculi as ILs (eg, GHC)

»» Moreover, central language features… - Elm

Racket

Agda

F#

Clean

Clojure

OCaml

Haskell J

Scheme

Scala

Standard ML

Erlang

SASL

SISAL

Id

ISWIM

Miranda

Hope

LISP

λ FP

21

* FLs: pragmatic renderings of lambda calculus with syntactic sugar etc for convenience.

* Important application: compilation via extended lambda calculi as ILs (eg, GHC)

»» Moreover, central language features… - Elm

Racket

Agda

F#

Clean

Clojure

OCaml

Haskell J

Scheme

Scala

Standard ML

Erlang

SASL

SISAL

Id

ISWIM

Miranda

Hope

LISP

λ FP

22

Central language features of FLs have their origin in the lambda calculus:

* HO functions & closures: lambda

* Purity & immutable structures: functional semantics

* Types & semantics: logic & Curry-Howard - Elm

Immutable

Racket

Agda

F#

Clean

structures

Purity

Clojure

OCaml

Haskell

Types

J

Scheme

Scala

Standard ML

Well-defiErlang

ned

SASL

SISAL

Higher-order

se Id

mantics

functions

ISWIM

Miranda

&

Hope

LISP

closures

λ FP

22

Central language features of FLs have their origin in the lambda calculus:

* HO functions & closures: lambda

* Purity & immutable structures: functional semantics

* Types & semantics: logic & Curry-Howard - Immutable

structures

Purity

Types

Well-defined

Higher-order

semantics

functions

&

closures

23

* Language features lead to practical advantages

* Some examples: <explain where they come from>

»» Nevertheless, we can gain even more from the foundation of FP than these advantages… - Immutable

Purity

structures

Types

Language features

Higher-order

Well-defined

functions

semantics

&

closures

23

* Language features lead to practical advantages

* Some examples: <explain where they come from>

»» Nevertheless, we can gain even more from the foundation of FP than these advantages… - Immutable

Purity

structures

Types

Language features

Higher-order

Well-defined

functions

semantics

&

closures

Practical advantages

23

* Language features lead to practical advantages

* Some examples: <explain where they come from>

»» Nevertheless, we can gain even more from the foundation of FP than these advantages… - Immutable

Purity

structures

Types

Language features

Higher-order

Well-defined

functions

semantics

&

closures

Concurrency

&

parallelism

Practical advantages

23

* Language features lead to practical advantages

* Some examples: <explain where they come from>

»» Nevertheless, we can gain even more from the foundation of FP than these advantages… - Immutable

Purity

structures

Types

Language features

Higher-order

Well-defined

functions

semantics

&

closures

Concurrency

&

parallelism

Practical advantages

Meta programming

23

* Language features lead to practical advantages

* Some examples: <explain where they come from>

»» Nevertheless, we can gain even more from the foundation of FP than these advantages… - Immutable

Purity

structures

Types

Language features

Higher-order

Well-defined

functions

semantics

&

closures

Concurrency

&

parallelism

Practical advantages

Meta programming

Reuse

23

* Language features lead to practical advantages

* Some examples: <explain where they come from>

»» Nevertheless, we can gain even more from the foundation of FP than these advantages… - Immutable

Purity

structures

Types

Language features

Higher-order

Well-defined

functions

semantics

&

closures

Concurrency

Strong

&

isolation

parallelism

Practical advantages

Meta programming

Reuse

23

* Language features lead to practical advantages

* Some examples: <explain where they come from>

»» Nevertheless, we can gain even more from the foundation of FP than these advantages… - Immutable

Purity

structures

Types

Language features

Higher-order

Well-defined

functions

semantics

&

closures

Concurrency

Strong

&

isolation

Safety

parallelism

Practical advantages

Meta programming

Reuse

23

* Language features lead to practical advantages

* Some examples: <explain where they come from>

»» Nevertheless, we can gain even more from the foundation of FP than these advantages… - Immutable

Purity

structures

Types

Language features

Higher-order

Well-defined

functions

semantics

&

closures

Concurrency

Strong

&

isolation

Safety

parallelism

Practical advantages

Meta programming

Reuse

Formal

reasoning

23

* Language features lead to practical advantages

* Some examples: <explain where they come from>

»» Nevertheless, we can gain even more from the foundation of FP than these advantages… - Part 2

From Language to Methodology

24

* Part 1: FP derives from natural, fundamental concept of computation...

* ...which is the root of language conveniences and practical advantages.

»» We want to take that concept one step further… - “Functional programming as a

development methodology,

not just a language category.”

25

» We want to use <read the statement>.

* Use the principles of the lambda calculus for a software development methodology.

[Engineering is based on science. This is the science of programming/software.]

»» To do this… - “The key to functional software

development is a consistent

focus on properties.”

26

» We need to realise that <read the statement>

* These can be "logical properties" or "mathematical properties".

»» More precisely, … - Properties

27

* Properties are rigorous and precise. (NB: PL is a formal notation.)

* We are not talking about specifying the entire behaviour of an applications. (Type

signatures are properties.)

* In one way or another, they leverage the formal foundation of the lambda calculus.

»» Let's look at some examples… - Properties

Rigorous, formal or semi-formal specification

Cover one or more aspects of a program

Leverage the mathematics of the lambda calculus

27

* Properties are rigorous and precise. (NB: PL is a formal notation.)

* We are not talking about specifying the entire behaviour of an applications. (Type

signatures are properties.)

* In one way or another, they leverage the formal foundation of the lambda calculus.

»» Let's look at some examples… - “A pure function is fully specified

by a mapping of argument to

result values.”

28

» Read the statement.

* Menas: if you know the arguments, you know the result.

* (1) Nothing else influences the result; (2) the function doesn't do anything, but provide the

result.

* This is semi-formal, but easy to formalise. - Well known property

“A pure function is fully specified

by a mapping of argument to

result values.”

28

» Read the statement.

* Menas: if you know the arguments, you know the result.

* (1) Nothing else influences the result; (2) the function doesn't do anything, but provide the

result.

* This is semi-formal, but easy to formalise. - map :: (a -> b) -> [a] -> [b]

eval :: Expr t -> t

n+m≡m+n : ∀ {n m : ℕ} -> m + n ≡ n + m

29

* map: well known

* eval: type-safe evaluator with GADTs

* Agda lemma: commutativity of addition

»» Types are not just for statically typed languages… - Types are properties

map :: (a -> b) -> [a] -> [b]

eval :: Expr t -> t

n+m≡m+n : ∀ {n m : ℕ} -> m + n ≡ n + m

29

* map: well known

* eval: type-safe evaluator with GADTs

* Agda lemma: commutativity of addition

»» Types are not just for statically typed languages… - Racket

(Scheme dialect)

30

* HTDP encourages the use of function signatures as part of the design process.

* It also uses data definitions (reminiscent of data type definitions)

* Racket also supports checked "contracts" - Racket

(Scheme dialect)

The Process: [..] 2. Write down a signature, [..]

30

* HTDP encourages the use of function signatures as part of the design process.

* It also uses data definitions (reminiscent of data type definitions)

* Racket also supports checked "contracts" - -- QuickCheck

prop_Union s1 (s2 :: Set Int) =

(s1 `union` s2) ==? (toList s1 ++ toList s2)

31

* In formal specifications

* But also useful for testing: QuickCheck

* Popular specification-based testing framework

»» And as the last example of a property… - Logic formulas

-- QuickCheck

prop_Union s1 (s2 :: Set Int) =

(s1 `union` s2) ==? (toList s1 ++ toList s2)

31

* In formal specifications

* But also useful for testing: QuickCheck

* Popular specification-based testing framework

»» And as the last example of a property… - -- return a >>= k == k a

-- m >>= return == m

-- m >>= (\x -> k x >>= h)

-- == (m >>= k) >>= h

class Monad m where

(>>=) :: m a -> (a -> m b) -> m b

return :: a -> m a

32

* Monads: categorial structures that needs to obey certain laws.

* Think of them as API patterns. - Algebraic and categorial structures

-- return a >>= k == k a

-- m >>= return == m

-- m >>= (\x -> k x >>= h)

-- == (m >>= k) >>= h

class Monad m where

(>>=) :: m a -> (a -> m b) -> m b

return :: a -> m a

32

* Monads: categorial structures that needs to obey certain laws.

* Think of them as API patterns. - I/O in Haskell

33

* Now that we have seen some examples of properties, ...

»» ...let's look at an example of guiding a design by properties… - Example of an uncompromising pursuit of properties

I/O in Haskell

33

* Now that we have seen some examples of properties, ...

»» ...let's look at an example of guiding a design by properties… - (not really Haskell)

readName

= let firstname = readString ()

in

let surname = readString ()

in

firstname ++ " " ++ surname

34

* Read two strings from stdin and combine them.

* In which order will firstname and surname be read?

* Non-strict (or lazy) language: compute when needed

»» Problem with I/O, as the following compiler optimisations demonstrate… - (not really Haskell)

readName

= let firstname = readString ()

in

let surname = readString ()

in

firstname ++ " " ++ surname

Haskell is a non-strict language

34

* Read two strings from stdin and combine them.

* In which order will firstname and surname be read?

* Non-strict (or lazy) language: compute when needed

»» Problem with I/O, as the following compiler optimisations demonstrate… - readName

= let firstname = readString ()

in

let surname = readString ()

in

firstname ++ " " ++ surname

35

* Two occurences of the same lambda term must have the same meaning. - Common subexpression elimination

readName

= let firstname = readString ()

in

let surname = readString

firstname

()

in

firstname ++ " " ++ surname

35

* Two occurences of the same lambda term must have the same meaning. - readName

= let firstname

firstname = readString ()

in

let surname

surname = readString

readString ()

()

in

firstname ++ " " ++ surname

36

* No data depencency between the two bindings - Reordering

readName

= let firstname

surname = = readString

readString

()

()

in

let surname = readString

firstname =

()

readString ()

in

firstname ++ " " ++ surname

36

* No data depencency between the two bindings - readName

= let firstname = readString ()

in

let surname = readString ()

in

firstname

37

* If a binding is not used, we should be able to eliminate it.

* 1988: Haskell language committee faced the problem of mismatch between non-strictness

and I/O

»» They saw two options… - Dead code elimination

readName

= let firstname = readString ()

in

let surname = readString ()

in

firstname

37

* If a binding is not used, we should be able to eliminate it.

* 1988: Haskell language committee faced the problem of mismatch between non-strictness

and I/O

»» They saw two options… - Option ❶

Destroy purity

38

»» To do so, they would need… - Destroy purity

39

» <Explain> - Destroy purity

Prohibit those code transformations

Enforce strict top to bottom evaluation of let bindings

39

» <Explain> - Destroy purity

Prohibit those code transformations

Not a good idea!

Enforce strict top to bottom evaluation of let bindings

39

» <Explain> - WG 2.8, 1992

40

[This is not the real committee, but a large part.]

* Didn't want to give up this property.

* Non-strictness kept them honest.

»» This left them with the second option… - Preserve those code

transformations

WG 2.8, 1992

40

[This is not the real committee, but a large part.]

* Didn't want to give up this property.

* Non-strictness kept them honest.

»» This left them with the second option… - We want local

Preserve those code

reasoning

transformations

WG 2.8, 1992

40

[This is not the real committee, but a large part.]

* Didn't want to give up this property.

* Non-strictness kept them honest.

»» This left them with the second option… - We want local

Preserve those code

reasoning

transformations

WG 2.8, 1992

Think about

concurrency

40

[This is not the real committee, but a large part.]

* Didn't want to give up this property.

* Non-strictness kept them honest.

»» This left them with the second option… - We want local

Preserve those code

reasoning

transformations

WG 2.8, 1992

Keep purity!

Think about

concurrency

40

[This is not the real committee, but a large part.]

* Didn't want to give up this property.

* Non-strictness kept them honest.

»» This left them with the second option… - Option ❷

Continuation-based &

Stream-based I/O

41

»» I don't want to explain them in detail, but here is an example… - readName :: [Response] -> ([Request], String)

readName ~(Str firstname : ~(Str surname : _))

= ([ReadChan stdin, ReadChan stdin],

firstname ++ " " ++ surname)

42

* Rather inconvenient programming model

* Due to lack of a better idea, Haskell 1.0 to 1.2 used continuation-based and stream-based

I/O

»» Can't we do any better… - readName :: [Response] -> ([Request], String)

readName ~(Str firstname : ~(Str surname : _))

= ([ReadChan stdin, ReadChan stdin],

firstname ++ " " ++ surname)

readName :: FailCont -> StrCont -> Behaviour

readName abort succ

= readChan stdin abort (\firstname ->

readChan stdin abort (\surname ->

succ (firstname ++ " " ++ surname)))

42

* Rather inconvenient programming model

* Due to lack of a better idea, Haskell 1.0 to 1.2 used continuation-based and stream-based

I/O

»» Can't we do any better… - “What are the properties of I/O,

of general stateful operations?”

43

* Let's take a step back.

» Can we use properties to understand the nature of I/O?

»» Let's characterise what stateful (imperative) computing is about… - Arguments

Result

State changing

function

44

* In addition to arguments and result...

* ...state is threaded through.

»» In the case of I/O… - Arguments

Result

State changing

function

State

State'

44

* In addition to arguments and result...

* ...state is threaded through.

»» In the case of I/O… - Arguments

Result

I/O function

45

* The state is the whole world

»» How can we formalise this… - Arguments

Result

I/O function

46

* Categorial semantics of impure language features: properties of impure features

* Lambda calculus with impure features

* Characterise the meaning of effects

»» How can we use that to write FPs… - Arguments

Result

I/O function

46

* Categorial semantics of impure language features: properties of impure features

* Lambda calculus with impure features

* Characterise the meaning of effects

»» How can we use that to write FPs… - Arguments

Result

I/O function

Monad!

Eugenio Moggi

46

* Categorial semantics of impure language features: properties of impure features

* Lambda calculus with impure features

* Characterise the meaning of effects

»» How can we use that to write FPs… - Eugenio Moggi

47

* Moggi's semantics is based on the lambda calculus

* So, it ought to translate to FLs

»» Finally, we can write our example program properly… - Eugenio Moggi

47

* Moggi's semantics is based on the lambda calculus

* So, it ought to translate to FLs

»» Finally, we can write our example program properly… - Eugenio Moggi

-- return a >>= k == k a

Philip Wadler

-- m >>= return == m

-- m >>= (\x -> k x >>= h)

-- == (m >>= k) >>= h

class Monad m where

(>>=) :: m a -> (a -> m b) -> m b

return :: a -> m a

instance Monad IO where

...

47

* Moggi's semantics is based on the lambda calculus

* So, it ought to translate to FLs

»» Finally, we can write our example program properly… - (Real Haskell!)

readName :: IO String

readName

= do firstname <- readString

surname <- readString

in return (firstname ++ " " ++ surname)

48

* Development oriented at properties

* Solution has an impact well beyond Haskell I/O

»» Functional software development usually doesn't mean to resort to abstract math… - Part 3

Applying the Methodology

49

* So far, we saw that the genesis of FP resolved around working with and exploiting logical &

mathematical properties.

»» To get a feel for using such properties, let us look at a concrete development effort, where

we used properties in many flavours to attack a difficult problem… - Pure data parallelism

50

»» Good parallel programming environments are important, because of… - Case study in functional software development

Pure data parallelism

50

»» Good parallel programming environments are important, because of… - Ubiquitous parallelism

multicore

CPU

multicore

GPU

51

* Today, parallelism is everywhere! <Explain>

»» We would like a parallel programming environment with meeting the following goals… - Goal ➀

Exploit parallelism of commodity hardware easily:

52

* We are not aiming at supercomputers

* Ordinary applications cannot afford the resources that go into the development of HPC

apps.

»» To this end… - Goal ➀

Exploit parallelism of commodity hardware easily:

Performance is important, but…

…productivity is more important.

52

* We are not aiming at supercomputers

* Ordinary applications cannot afford the resources that go into the development of HPC

apps.

»» To this end… - Goal ➁

Semi-automatic parallelism:

53

* Not fully automatic: computers cannot parallelise algos & seq algos are inefficient on

parallel hardware.

* Explicit concurrency is hard, non-modular, and error prone.

»» How can properties help us to achieve these two goals… - Goal ➁

Semi-automatic parallelism:

Programmer supplies a parallel algorithm, but

no explicit concurrency (no concurrency control, no races,

no deadlocks).

53

* Not fully automatic: computers cannot parallelise algos & seq algos are inefficient on

parallel hardware.

* Explicit concurrency is hard, non-modular, and error prone.

»» How can properties help us to achieve these two goals… - Three property-driven methods

54

Types: track purity, generate array representations, guide optimisations

State minimisation: localised state transformers, immutable structures

Combinators: parallelisable aggregate array operations, exploit algebraic properties,

restricted language for special hardware - Three property-driven methods

Types

54

Types: track purity, generate array representations, guide optimisations

State minimisation: localised state transformers, immutable structures

Combinators: parallelisable aggregate array operations, exploit algebraic properties,

restricted language for special hardware - Three property-driven methods

Types

State minimisation

54

Types: track purity, generate array representations, guide optimisations

State minimisation: localised state transformers, immutable structures

Combinators: parallelisable aggregate array operations, exploit algebraic properties,

restricted language for special hardware - Three property-driven methods

Types

State minimisation

Combinators & embedded languages

54

Types: track purity, generate array representations, guide optimisations

State minimisation: localised state transformers, immutable structures

Combinators: parallelisable aggregate array operations, exploit algebraic properties,

restricted language for special hardware - Ubiquitious parallelism

multicore

CPU

multicore

GPU

55

»» What kind of code do we want to write for parallel hardware… - smvm :: SparseMatrix -> Vector -> Vector

smvm sm v = [: sumP (dotp sv v) | sv <- sm :]

56 - smvm :: SparseMatrix -> Vector -> Vector

smvm sm v = [: sumP (dotp sv v) | sv <- sm :]

56 - smvm :: SparseMatrix -> Vector -> Vector

smvm sm v = [: sumP (dotp sv v) | sv <- sm :]

2 1.5

5

3

4

7 6.5

1

sm

v

57 - smvm :: SparseMatrix -> Vector -> Vector

smvm sm v = [: sumP (dotp sv v) | sv <- sm :]

2 1.5

5

3

4

7 6.5

1

sm

v

57 - smvm :: SparseMatrix -> Vector -> Vector

smvm sm v = [: sumP (dotp sv v) | sv <- sm :]

2 1.5

5

3

4

7 6.5

1

sm

v

57 - smvm :: SparseMatrix -> Vector -> Vector

smvm sm v = [: sumP (dotp sv v) | sv <- sm :]

Σ

2 1.5

Σ

Σ

5

3

Σ

4

7 6.5

Σ

1

sm

v

57 - smvm :: SparseMatrix -> Vector -> Vector

smvm sm v = [: sumP (dotp sv v) | sv <- sm :]

Σ

2 1.5

Σ

Σ

5

3

Σ

4

7 6.5

Σ

1

sm

v

57 - “Types ensure purity, purity

ensures non-interference.”

58

* Functions that are not of monadic type are pure.

* Pure functions can execute in any order, also in parallel.

=> No concurrency control needed [Properties pay off — Types.]

»» But we need more than a convenient notation… - Types

“Types ensure purity, purity

ensures non-interference.”

58

* Functions that are not of monadic type are pure.

* Pure functions can execute in any order, also in parallel.

=> No concurrency control needed [Properties pay off — Types.]

»» But we need more than a convenient notation… - High performance

59

* Performance is not the only goal, but it is a major goal.

* Explain fluid flow.

»» We can get good performance… - 60

* Repa (blue) is on 7 CPU cores (two quad-core Xenon E5405 CPUs @ 2 GHz, 64-bit)

* Accelerate (green) is on a Tesla T10 processor (240 cores @ 1.3 GHz)

* Repa talk: Ben Lippmeier @ Thursday before lunch

* Accelerate talk: Trevor McDonell @ Friday before lunch - Jos Stam's Fluid Flow Solver

60

* Repa (blue) is on 7 CPU cores (two quad-core Xenon E5405 CPUs @ 2 GHz, 64-bit)

* Accelerate (green) is on a Tesla T10 processor (240 cores @ 1.3 GHz)

* Repa talk: Ben Lippmeier @ Thursday before lunch

* Accelerate talk: Trevor McDonell @ Friday before lunch - “How do we achieve high

performance from purely

functional code?”

61

»» This presents an inherent tension… - Unboxed,

mutable arrays

C-like

loops

62

»» We resolve this tension with local state… - Performance

Unboxed,

mutable arrays

C-like

loops

62

»» We resolve this tension with local state… - Performance

Unboxed,

mutable arrays

Pure

functions

C-like

loops

62

»» We resolve this tension with local state… - Parallelism &

Performance

Optimisations

Unboxed,

mutable arrays

Pure

functions

C-like

loops

62

»» We resolve this tension with local state… - Parallelism &

Performance

Optimisations

Unboxed,

mutable arrays

Pure

functions

C-like

loops

62

»» We resolve this tension with local state… - (Pure)

map :: (Shape sh, Source r a)

=> (a -> b)

-> Array r sh a

-> Array D sh b

63

* We use a library of pure, parallel, aggregate operations

* In Repa, types guide array representations

»» Despite the pure interface, some combinators are internally impure… - Types

(Pure)

map :: (Shape sh, Source r a)

=> (a -> b)

-> Array r sh a

-> Array D sh b

63

* We use a library of pure, parallel, aggregate operations

* In Repa, types guide array representations

»» Despite the pure interface, some combinators are internally impure… - Local state

64

<Explain>

* Program transformations and parallelisation on pure level

* Then, unfold and optimise imperative program

* Type system helps to get this right

* Fusion - Local state

Allocate mutable array

64

<Explain>

* Program transformations and parallelisation on pure level

* Then, unfold and optimise imperative program

* Type system helps to get this right

* Fusion - Local state

Allocate mutable array

Initialise destructively

64

<Explain>

* Program transformations and parallelisation on pure level

* Then, unfold and optimise imperative program

* Type system helps to get this right

* Fusion - Local state

Allocate mutable array

Initialise destructively

Freeze!

64

<Explain>

* Program transformations and parallelisation on pure level

* Then, unfold and optimise imperative program

* Type system helps to get this right

* Fusion - Sta

m

te

inimisation

Local state

Allocate mutable array

Initialise destructively

Freeze!

64

<Explain>

* Program transformations and parallelisation on pure level

* Then, unfold and optimise imperative program

* Type system helps to get this right

* Fusion - Sta

ators

m

te

inim

bin

isation

Com

Local state

Allocate mutable array

Initialise destructively

Freeze!

64

<Explain>

* Program transformations and parallelisation on pure level

* Then, unfold and optimise imperative program

* Type system helps to get this right

* Fusion - Special hardware

THREADS

12 THREADS

24,576

Core i7 970

NVIDIA GF100

CPU

GPU

65

* Straight forward code generation is not suitable for all architectures

»» GPUs are highly parallel, but also restricted in which operations are efficient… - GPU's don't like

66

* We won't compile all of Haskell to GPUs anytime soon. - GPU's don't like

SIMD divergence (conditionals)

66

* We won't compile all of Haskell to GPUs anytime soon. - GPU's don't like

SIMD divergence (conditionals)

Recursion

66

* We won't compile all of Haskell to GPUs anytime soon. - GPU's don't like

SIMD divergence (conditionals)

Recursion

Function pointers

66

* We won't compile all of Haskell to GPUs anytime soon. - GPU's don't like

SIMD divergence (conditionals)

Recursion

Function pointers

Automatic garbage collection

66

* We won't compile all of Haskell to GPUs anytime soon. - dotpAcc :: Vector Float

-> Vector Float

-> Acc (Scalar Float)

dotpAcc xs ys

= let

xs' = use xs

ys' = use ys

in

fold (+) 0 (zipWith (*) xs' ys')

67

* We special purpose compile embedded code. - Acc marks embedded computations

dotpAcc :: Vector Float

-> Vector Float

-> Acc (Scalar Float)

dotpAcc xs ys

= let

xs' = use xs

ys' = use ys

in

fold (+) 0 (zipWith (*) xs' ys')

67

* We special purpose compile embedded code. - Acc marks embedded computations

dotpAcc :: Vector Float

-> Vector Float

-> Acc (Scalar Float)

dotpAcc xs ys

= let

xs' = use xs

ys' = use ys

in

fold (+) 0 (zipWith (*) xs' ys')

use embeds values

67

* We special purpose compile embedded code. - Em

Acc marks embedded computations

bedde

lang

d

uage

dotpAcc :: Vector Float

-> Vector Float

-> Acc (Scalar Float)

dotpAcc xs ys

= let

xs' = use xs

ys' = use ys

in

fold (+) 0 (zipWith (*) xs' ys')

use embeds values

67

* We special purpose compile embedded code. - types

>< state

languages

68 - Functional programming is

fundamental to computing

Functional software development is

property-driven development

types

>< state

languages

68 - Thank you!

69