INF2810: Funksjonell Programmering. Køer, tabeller, og (litt om) parallelitet

Transkript

1 INF2810: Funksjonell Programmering Køer, tabeller, og (litt om) parallelitet Stephan Oepen & Erik Velldal Universitetet i Oslo 5. april 2013

2 Tema 2 Siste gang Kort om underveisevaluering Destruktive listeoperasjoner Implementasjon av køer Den store INF2810-påskequizzen I dag Litt mer i dybden om køer Eksperiment: live-programmering Tabeller som hierarkiske lister Grunnleggende om parallelitet

3 Repetisjon: Spørsmål 1 (omgivelser) 3 (a) Hvor mange nye omgivelser oppstår under evaluering av dette uttrykket? (b) Hva er resultatet av evalueringen? (define foo 41) (let ((foo (+ foo 1))) ((lambda (foo) (* foo 2)) foo)) (a) let, +, oppkalling av anonym prosedyre, *: 4 (2 poeng). (b) (* (+ 41 1) 2) 84 (1 poeng).

4 Vi gratulerer! I Ganske eksamensrelevante spørsmål; vinnerlaget med 12 av 20 poeng. 4

5 Destruktive listeoperasjoner 5 Når tilordningen til symbol kan endres, hva med komplekse objekter? Med set-car! og set-cdr! kan tilordninger innenfor et par endres.? (define foo (0 2 2))? (set-car! foo 1)? foo (1 2 2)? (set-car! (cddr foo) 3)? foo (1 2 3) Så langt brukte vi cons-celler som lim for komplekse datastrukturer. Kan nå definere mutators i tillegg til constructor, selectors, og predicate. Det kan være hensiktsmessig for å minimere bruk av minne (plass).

6 Destruktiv Listekonkatenasjon 6 (define (append! front tail) (if (null? (cdr front)) (set-cdr! front tail) (append! (cdr front) tail)))? (define foo (1 2))? (define bar (3 4))? (append! foo bar)? foo ( ) Vår prosedyre append! er destruktiv siden (verdien til) foo endres. Ennå mer aliasing? (append! foo bar)? foo (1 2. #0=(3 4. #0#))

7 Litt mer trening på destruktive listeoperasjoner 7 (define (foo bar) (if (null? bar) () (cons (car bar) (foo (cdr bar)))))? (define baz ((a b) c))? (define fee (foo baz))? (equal? baz fee) #t? (eq? baz fee) #f? (set-cdr! baz (d))? baz ((a b) d)? fee ((a b) c)? (set-car! (car baz) b)? baz ((b b) d)? fee ((b b) c)

8 Køer (implementert på grunnlag av lister) 8 En kø (queue) er en rettferdig datastruktur: first in, first out (FIFO). Kan implementeres som liste, sammen med først - og sist -pekere. Nye objekter legges til på slutten; objekter kan kun fjernes fra fronten. Kunne vi klart oss med bare en liste (én cons per elementet i køen)?

9 Køer som abstrakt datatype 9 make-queue ingen parametre; returnerer en tom kø. queue-empty? queue-insert! queue-extract! ett parameter; tester for tomhet. setter første parameteret inn i andre parameteret. ett parameter; tar ut og returnerer første objektet. Nå skal vi prøve oss på live-programmering.

10 (Assosiative) Tabeller 10 Også assosiative tabeller kan implementeres med cons-celler i bunnen. Lime sammen nøkkel, verdi -par som cons; så samle de som en liste. Noen operasjoner kan forenkles ved å sette én ekstra cons-celle foran. En slik headed list kan også bruke allerførste car som typemerkelapp.

11 Endimensionale tabeller som lister 11 (define (make-table) (list *table*)) (define (assoc key records) (cond ((null? records) #f) ((equal? key (caar records)) (car records)) (else (assoc key (cdr records))))) (define (lookup key table) (let ((record (assoc key (cdr table)))) (and record (cdr record)))) (define (insert! key value table) (let ((record (assoc key (cdr table)))) (if record (set-cdr! record value) (set-cdr! table (cons (cons key value) (cdr table)))))) nøkkel, v erdi -lister heter assoc-lister og støttes i Scheme (og Lisp).

12 Noen refleksjoner rundt tabeller 12 I denne (naïve) implementasjonen, hvilken tidskompleksitet har det å slå opp verdien til en nøkkel? å legge inn et nøkkel, v erdi -par? Kompleksiteten kan forbedres hvis nøklene sorteres binære trær. Vi husker at cons-celler kunne implementeres som prosedyreobjekter; dette kan utvides til destruktive operasjoner (set-car! og set-cdr!). Med mange elementer kan det lønne seg å bruke en hashtabell isteden. Common Lisp har hashtabeller som innebygd datatype, enn ikke R5RS. Men Scheme har støtte for fast dimensionerte felt (vector eller array). Multidimensjonale tabeller kan realiseres ved å nøste assoc-tabeller.

13 En todimensjonal tabell 13

14 Veldig kort om parallelitet (1/4) 14 Med set! introduserte vi elementer fra imperativ programmering: Verditilordning og tilstandsendring som modifiserer objekter. Bankkonto er en muterbar objekt, med tidsavhengig tilstand. I ren funskjonell programmering derimot var ting statisk over tid: Semantikken til et uttrykk var uavhengig av hvor og når det brukes. Derfor kan (rent) funksjonelle programmer uten videre paralleliseres. Med tidsavhengig tilstand trengs det mekanismer for synkronisering. Problem: destruktive prosedyrer som deler på noen felles ressurser.

15 Veldig kort om parallelitet (2/4) 15

16 Veldig kort om parallelitet (3/4) 16 Suppose that Peter, Paul, and Mary share a joint bank account that initially contains $100. Concurrently, Peter deposits $10, Paul withdraws $20, and Mary withdraws half the money in the account. Peter (set! balance (+ balance 10)) Paul (set! balance (- balance 20)) Mary (set! balance (- balance (/ balance 2))) Hvor mange mulige sluttsaldoer, hvis hvert set!-uttrykk var atomært? Hvor mange muligheter uten hvilke som helst antakelser om rekkefølge? Hva er kritiske punkter med tanke på parallelitet og tidsdimensjonen?

17 Veldig kort om parallelitet (4/4) 17 For å synkronisere rundt bruk av felles ressurser brukes semaphores; (aka mutex or lock) som ble først diskutert av Edsger Dijkstra (1965). Før kritisk avsnitt, få tak i semaphoren (acquire); Ved utgang fra kritisk avsnitt, slippe (release). Prosesser blokkeres under venting på semaphoren. (define (make-account) (let ((balance 0) (mutex (make-mutex))) (define (deposit amount) (mutex acquire) (set! current (+ current amount))) (mutex release) ))