part 1 : programming and abstraction

44
Workshop: Towards Highly Portable Software Jakarta, 21 – 23 January 2003 Diselenggarakan oleh Universitas Indonesia Part 1 : Programming and Abstraction Dr. Ir. I.S.W.B. Prasetya [email protected] A. Azurat S.Kom. [email protected] Lecture 1: Functional Programming

Upload: sveta

Post on 21-Jan-2016

38 views

Category:

Documents


0 download

DESCRIPTION

Part 1 : Programming and Abstraction. Lecture 1: Functional Programming. Dr. Ir. I.S.W.B. [email protected] A. Azurat [email protected]. Content. Functional programming style Syntax Types Tree recursion Laziness Circularity Practice. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Part 1 : Programming and Abstraction

Workshop: Towards Highly Portable SoftwareJakarta, 21 – 23 January 2003

Diselenggarakan oleh Universitas Indonesia

Part 1 : Programming and Abstraction

Dr. Ir. I.S.W.B. Prasetya [email protected]. Azurat S.Kom. [email protected]

Lecture 1: Functional Programming

Page 2: Part 1 : Programming and Abstraction

2

Content

• Functional programming style– Syntax

– Types

– Tree recursion

– Laziness

– Circularity

• Practice

FP is a big subject... we will only take the highlights.

Page 3: Part 1 : Programming and Abstraction

3

Problem

• Computing salary

• It's not difficult

• So, why do we pay lots of money to automate it !?

Page 4: Part 1 : Programming and Abstraction

4

Programming

• Programming: – Algorithmic aspect: how to solve a problem

– Communication aspect: tell the computer how to do it

• Algorithm intertesting

• Communication annoying!

(especially talking to something that only chat in 0 and 1...)

Lots of language-specific detail which has nothing to do with the actual problem.

Page 5: Part 1 : Programming and Abstraction

5

Programming

• Communication with a computer is a big problem....

Precision is needed formal communication with programming language.

Formalism constrains communication, making it difficult production cost.

• Communication in general is a big problem...

Multiply errors: communication errors.

Page 6: Part 1 : Programming and Abstraction

6

Abstraction

• Real world is too complex ... our mind precieve only an abstraction of it.

Abstract: not real...

Blindness is power!

Page 7: Part 1 : Programming and Abstraction

7

Thesis 1: Abstraction

The key towards low cost software is to teach the compiler, not the programmer.

Page 8: Part 1 : Programming and Abstraction

8

Functional Programming

• Use function as an abstract concept of what a program is.

• What do we 'abstract' away?– Pointers

– Garbage collection

– In-situ array

– I/O

• Very suitable for program transformation

• Why not Java??– Use the right tool to do the right thing

Page 9: Part 1 : Programming and Abstraction

9

Functional Programming Languages

• LISP, Scheme, Miranda, ML, Clean, Haskell

• Variations:– Strongly typed, untyped

– Lazy, Strict

– Pure, impure

• We're using Haskell

Site: www.haskell.org

Sophisticated compilers and other tools avaialble for free!

• For education, check out Helium: www.cs.uu.nl/~afie/helium

Page 10: Part 1 : Programming and Abstraction

10

Example

del :: Int -> [Int] -> [Int]

del x [ ] = [ ]

del x (y:s)

| x==y = del x y

| otherwise = y : del x y

Page 11: Part 1 : Programming and Abstraction

11

You can also do it with less abstraction...

void del0 (*int t)

{if (null t) {return()}

else if (t->item == 0) {*int s = t ; t = t->next free(s) ; del0(t) ; return() ; }

else {del0(t->next); return(); }

}

Error rate, and thus production and maintenance cost increases with the

ammount of 'dirty' code you have to write.

Page 12: Part 1 : Programming and Abstraction

12

Types

• Basic types: Bool, Int, Char• Tuple: (Int,Int)• List: [Bool], [Int]• Function: Bool -> Int• Type variable a,b,c,...• Polymorphic type [a]• Self defined type

• More sophisticated:– Record– IO– Array

Page 13: Part 1 : Programming and Abstraction

13

Polymorphism

del :: Int -> [Int] -> [Int]

del x [ ] = [ ]

del x (y:s)

| x==y = del x y

| otherwise = y : del x y

a -> [a] -> [a]

Page 14: Part 1 : Programming and Abstraction

14

Higher Order Function

• Traditionally, a program is used to process data.

data program data

• Why not pass program to as data?

data program data

program

Page 15: Part 1 : Programming and Abstraction

15

Higher Order Function

filter :: (a->Bool) -> [a] -> [a]

filter p [ ] = [ ]

filter p (x:s)

| p x = x : filter p s

| otherwise = filter p s

Page 16: Part 1 : Programming and Abstraction

16

Higher Order Function

del x s = filter p s

where

p y = x/=y

search :: String -> String -> [String]

search w txt = filter p (words txt) where

p z = isPrefixOf w z

Page 17: Part 1 : Programming and Abstraction

17

Higher Order Function

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

map f [ ] = [ ]

map f (x : s) = f x : map f s

capitalize :: String -> String

capitalize s = map toUpper s

Page 18: Part 1 : Programming and Abstraction

18

Partial Parametrization

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

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

capitalize s = map toUpper s

Example, recall:

map toUpper

map toLower . map toUpper

Page 19: Part 1 : Programming and Abstraction

19

Abstraction

query :: [Employee] -> [Transaction] -> [Transaction]

query es ts = (concat . map find . filter isManager) es where find employee = filter p ts where p transaction = #id transaction == #id employee

Given a database of employee and a database of transactions, make a query to produce a list of all transactions made by all managers.

Page 20: Part 1 : Programming and Abstraction

20

Syntax Sugar

• What's the point of being ellegant!?

Express things naturally (intuitively) is as little words as possible.

• Haskel syntax sugars:– priority and associativity

– infix and sufix coercion

– sectioning

– list comprehension

– many more....

Page 21: Part 1 : Programming and Abstraction

21

Priority and Associativity

• Write

x + y * z rather than x + (y * z)

x : y : s rather than x : (y : s)

• Priority : 0 .. 9 see Prelude.hs

• Associativity: left, right, non-assoc

Page 22: Part 1 : Programming and Abstraction

22

Coercion and Sectioning

• Infix coercion:

f `map` s instead of map f s

• Prefix coercion:

(+) x y instead of x + y

• Sectioning:

(++ t) means (\s-> s ++ t)(t ++) means (\u-> t ++ u)

Page 23: Part 1 : Programming and Abstraction

23

List Comprehension

• Example: [x + 1 | x <- s, x>0]

• Combo of map and filter

query :: [Employee] -> [Transaction] -> [Transaction]

query es ts = (concat . map find . filter isManager) es where ...

query es ts = concat [find e | e <- es, isManager e]

Page 24: Part 1 : Programming and Abstraction

24

Introducing New Types

• Type abbreviation:

type PersonDB = [Person]

• data-type definition:

data Color = Red | Green | Blue

• With parameter:

data Maybe a = Nothing | Just a

Page 25: Part 1 : Programming and Abstraction

25

Recursive Data Type

data List a =

Empty

| Cons a (List a)

length :: List a -> Int

length Empty = 0

length (Cons x s) = 1 + length s

Page 26: Part 1 : Programming and Abstraction

26

Representing Tree

data Btree a =

Node a (Btree a) (Btree a)

| Leaf a

Example:

Node 10 (Leaf 0) (Leaf 20)

10

0 20

Page 27: Part 1 : Programming and Abstraction

27

Tree Recursion

data Btree a = Node a (Btree a) (Btree a)| Leaf a

minT :: Btree a -> a

minT (Leaf x) = x

minT (Node x t u) = x `min` minT t `min` minT u

Page 28: Part 1 : Programming and Abstraction

28

Tree Recursion

replace :: a -> Btree a -> Btreea

replace x (Leaf _ ) = Leaf x

replace x (Node _ t u) = Node x t' u'wheret' = replace x tu' = replace x u

repmin t = replace (minT t) t

Page 29: Part 1 : Programming and Abstraction

29

Debugging with the Type Checker

• Exploit your type checker to debug your programs...

Example:

use Data Week = Monday | Tuesday | ...

Type checker will reject this:

if day - 1 < - 1 then ...

Page 30: Part 1 : Programming and Abstraction

30

Debugging with the Type Checker

• Representing Red/Blue tree:

With Btree:

Node Blue (Leaf Red) (Leaf Red)

• Not all Btree is a Red/Blue tree

You'll have to implement the check yourself...

Page 31: Part 1 : Programming and Abstraction

31

Mutual Recursion

odd 0 = Falseodd (n+1) = even n

even 0 = Trueeven (n+1) = odd n

data RedRootTree RedNode BlueRootTree BlueRootTree| RedLeaf

data BlueRootTree BlueNode RedRootTree RedRootTree | BlueLeaf

Page 32: Part 1 : Programming and Abstraction

32

Laziness...

• Consider this definition:

True || b = Truea || True = Truea || b = False

• What happen if we evaluate this?

(x>0) || find (==x) [0 .. ]

Page 33: Part 1 : Programming and Abstraction

33

Laziness

• Laziness intelligently breaks recursion:

find :: (a->Bool) -> [a] -> Bool

find p [ ] = False

find p (x : s) = p x || find p s

• Often lead to more ellegant solutions:

fillSpaceRight n s = take n (s ++ repeat ' ')

Page 34: Part 1 : Programming and Abstraction

34

Lazily Walking a Tree...

• repmin:

Replace all elements in a tree with its minimum.

• We did it in sequence: compute minimum first, then do replacement.

We explicitly program this sequence.

repmin t = replace (minT t) t

Page 35: Part 1 : Programming and Abstraction

35

Lazily Walking a Tree...

repmin t = u

where

(u, m) = foldT t m

foldT (Leaf x) m = (Leaf m, x)

foldT (Node x t u) m = (Node m t' u', z)

wherez = x `min` mt `min` mu(t' , mt) = foldT t m(u' , mu) = foldT u m

Lazy evaluation will discover the correct order of 'attributes' computation

Page 36: Part 1 : Programming and Abstraction

36

Classes

• Overloading: using the same name for different 'meaning'

True == False1 == 1[1,2,3] == [ ]

• Class in Haskell:

Eq a where (==) :: a -> a -> Bool (/=) :: a -> a -> Bool x /= y = not (x == y)

Page 37: Part 1 : Programming and Abstraction

37

Instances

instance Eq Bool where

True == True = True False == False = True _ == _ = False

instance Eq a => Eq [a] where

[ ] == [ ] = True

(x:s) == (y:t) = (x==y) && s==t

_ == _ = False

Examples:

Page 38: Part 1 : Programming and Abstraction

38

Use

del :: a -> [a] -> [a]

del x [ ] = [ ]

del x (y:s)

| x==y = del x y

| otherwise = y : del x y

Eq a => a -> [a] -> [a]

Page 39: Part 1 : Programming and Abstraction

39

I/O

• IO is in principle non-functional

• In Haskell IO actions are actracted by the type IO a

A value of this type is an IO action that produces a value of type a

Contains in principle no information regarding what kind of IO action it is.

Page 40: Part 1 : Programming and Abstraction

40

Some basic IO functions

• putStr :: String -> IO( )

• getChr :: IO Char

• getLine :: IO String

• readFile :: FilePath -> IO String

• writeFile :: FilePath -> String -> IO( )

Page 41: Part 1 : Programming and Abstraction

41

Sequencing IO actions

displayCountFile :: FilePath -> IO()

displayCountFile fname = do

{ content <- readFile fname ;

n <- return (length (words content)) ;

putStr (show n)

}

Page 42: Part 1 : Programming and Abstraction

42

Manipulating IO

• An IO a value is a value like a any other Haskell value.

You can manipulate it at will...

Example:

sequence (map displayCountFile fileList)

Page 43: Part 1 : Programming and Abstraction

43

Some Haskell Syntax Rules

• Case sensitive

• Name of concrete type, data constructor, type constrytor begin with UPPER case character

• Name of function, variable, type variable begin with lower case character

• Haskell use strict identation rule ...

Page 44: Part 1 : Programming and Abstraction

44

Type error

• Be prepared to get depressed by Haskell's type error

Haskell type checker/inference is very powerful.

• Type messaging system is somewhat less developed.

Improvement in on the way ... e.g. the new type checker by B. Heeren (used in Helium)