York University www.cs.york.ac.uk/~ndm First order vs Higher - - PowerPoint PPT Presentation

york university cs york ac uk ndm first order vs higher
SMART_READER_LITE
LIVE PREVIEW

York University www.cs.york.ac.uk/~ndm First order vs Higher - - PowerPoint PPT Presentation

First Order Haskell Neil Mitchell York University www.cs.york.ac.uk/~ndm First order vs Higher order Higher order: functions are values Can be passed around Stored in data structure Harder for reasoning and analysis More


slide-1
SLIDE 1

First Order Haskell

Neil Mitchell York University www.cs.york.ac.uk/~ndm

λ

slide-2
SLIDE 2

First order vs Higher order

 Higher order: functions are values

– Can be passed around – Stored in data structure

 Harder for reasoning and analysis

– More syntactic forms – Extra work for the analysis

 Can we convert automatically?

– Yes (that’s this talk!)

slide-3
SLIDE 3

Which are higher order?

[not x | x ← xs] let xs = x:xs in xs putChar ‘a’ 1 \x → not x not . odd not $ odd x map not xs foldl (+) 0 xs a < b (+1) const ‘N’

slide-4
SLIDE 4

Higher order features

 Type classes are implemented as dictionaries

– (==) :: Eq a

a → a → Bool

– (==) :: (a→a→Bool, a→a→Bool) → a → a → Bool

 Monads are higher order

– (>>=) :: Monad m

m a → (a → m b) → m b

 IO is higher order

– newtype IO a = IO (World → (World, a))

slide-5
SLIDE 5

A map example

map f [] = [] map f (x:xs) = f x : map f xs heads xs = map head xs

 head is passed higher order  map takes a higher order argument  heads could be first order

slide-6
SLIDE 6

Reynold’s Style Defunctionalisation

data Func = Head apply Head x = head x map f [] = [] map f (x:xs) = apply f x : map f xs heads xs = map Head xs

 Move functions to data

John C. Reynolds, Definitional Interpreters for Higher-Order Programming Languages

slide-7
SLIDE 7

Reynold’s Style Defunctionalisation

 Good

– Complete, works on all programs – Easy to implement

 Bad

– No longer Hindley-Milner type correct – Makes the code more complex – Adds a level of indirection – Makes program analysis harder

slide-8
SLIDE 8

Specialisation

map_head [] = [] map_head (x:xs) = head x : map_head xs heads xs = map_head xs

 Move functions to code

slide-9
SLIDE 9

Specialisation

 Find: map head xs

– A call to a function (i.e. map) – With an argument which is higher order (i.e. head)

 Generate: map_head xs = …

– A new version of the function – With the higher order element frozen in

 Replace: map_head xs

– Use the specialised version

slide-10
SLIDE 10

Specialisation fails

(.) f g x = f (g x) even = (.) not odd check x = even x

 Nothing available to specialise!  Can be solved by a simple inline

check x = (.) not odd x

slide-11
SLIDE 11

An algorithm

1.

Specialise as long as possible

2.

Inline once

3.

Goto 1

Stop when no higher order functions remain

slide-12
SLIDE 12

Algorithm fails

data Wrap a = Wrap (Wrap a) | Value a f x = f (Wrap x) check = f (Value head)

 In practice, this is rare – requires a function to

be stored in a recursive data structure and …

 Detect, and revert to Reynold’s method

slide-13
SLIDE 13

Code Size

 Specialisation approach reduces code volume

– Average about 55% smaller code (20%-95% range)

Mark Jones, Dictionary-free Overloading by Partial Evaluation

500 1000 1500 2000 2500 3000 Nofib Programs (Imaginary) Lines of Code Higher order First order

slide-14
SLIDE 14

Current uses

 Performance optimiser

– The first step, makes the remaining analysis simpler – Already increases the performance

 Analysis tool

– Catch, checking for pattern match safety – Keeps the analysis simpler

 Implemented for Yhc (York Haskell Compiler)

slide-15
SLIDE 15

Conclusion

 Higher order functions are good for

programmers

 Analysis and transformation are simpler in a

first order language

 Higher order functions can be removed  Their removal can reduce code size