INF2810 Funksjonell programmering 1. forelesning Buzz Words

Transkript

1 INF2810 Funksjonell programmering 1. forelesning Først i denne forelesningen en presentasjon av funksjonell programmering, med en masse mer eller mindre forståelige ord. I løpet av noen uker vil dere ha forstått det meste og ved kursets slutt vil dere forstå alt (vi tar en sjekk ved repetisjonen). Deretter en introduksjon til språket Scheme: grensesnitt dvs. programmeringsomgivelser grunnlegende begreper og kodeeksempler. Buzz Words Vi ser på noen av de begreper som dukker opp ved søk påfunctional programming på nettet. lambda calculus first class objekts currying closure lazy evaluation delayed evaluation streams concurrency Konvensjon: A ==> B betyr A evaluerer til B (B er resultatet av evalueringen av A). 1 2 lambda calculus også skrevet calculus first class objects, Med -kalkyle får vi et -uttrykk evaluerer til en prosedyre x. x + x ==> en prosedyre som tar ett argument og legger dette til seg selv. variabel kropp la f = x. x + x. Da evaluerer f(3) til 6, men det gjør også ( x. x + x)(3). Her har vi erstattet f med definisjonen av f og anvendt resultatet av evalueringen av definisjonen på argumentet 3. prosedyrer som opptrer som egne objekter på linje med andre objekter som tall, strenger, lister, etc. Vi sier at prosedyrer er førsteklasses objekter Prosedyren p tar 3 argumenter hvorav det første er en prosedyre, og anvender prosedyren på de to etterfølgende argumentene p(+, 7, 4) ==> 11 p(, 7, 4) ==> 3 p(*, 7, 4) ==> 28 p(( x y. x 2 + y 2 ), 7, 4) ==> 63 Dette er i praksis for enkelt til å være nyttig, men det illustrerer poenget. Etterhvert skal vi skrive prosedyrer der nytten av å kunne bruke prosedyreargumenter er helt åpenbar. 3 4

2 currying fra én flerargumentprosedyre til et nøste av énargumentsprosedyrer og vice versa. f(x, y) kan skrives om til f(x)(y) der f(x) evaluerer til en prosedyre. closure innpakking av én prosedyre i en annen. En closure er en førsteklasses prosedyre med frie variabler som er bundet i prosedyrens omgivelse. Forfatterne av SICP mener at denne bruken av begrepet closure er uheldig. Begrepet tilhører abstrakt algebra, der vi f.eks. sier at tallene er lukket under addisjon fordi summen av to tall selv er et tall (se fotnote SICP, s. 98). I -notasjon definerer vi f slik: La g = f(2) f = x. y. x + y. da får vi g ==> y. 2 + y. en prosedyre som tar ett argument og legger 2 til dette og g(3) ==> 5 som er det samme som f(2)(3) ==> 5 5 Et eksempel y. x + y, (1) Her er x fri og y bundet. f = x. y. x + y (2) Her er både x og y bundet g = f(2). (3) etter utførelsen av (3) er g et objekt bestående av en omgivelse der x er bundet til 2. og prosedyrekoden med variabel og kropp, Closure brukes bl.a. for å skjule tilstandsinformasjon i et funksjonelt program. Closure gir også en god semantikk for objektorientert programmering 6 Prosedyreobjektet Omgivelse x = 2 variabel y. kropp x + y lazy evaluation beregninger utføres bare hvis de er nødvendige hvis A, utfør B, og hvis ikke, utfør C. delayed evaluation (også en form for lazy evaluation) beregninger utsettes til de, om noensinne, blir nødvendige, og dermed unngår vi unødvendige beregninger. I de fleste språk evalueres valgsetninger som if A then B else C på denne måten. Dette gjelder også Scheme, der det ser slik ut (if A B C), men i Scheme kan vi i tillegg definere egne syntaktiske former som også evalueres på denne måten. uendelig verdisekvenser også kalt strømmer definering av uendelige sekvenser og realisering de enkelte elementene i disse ved utsatt evaluering etter behov. Dette får vi til vha. closure og delayed evaluation. Merk forskjellen mellom strømmer på den ene siden og arrays og lister på den andre. De siste vil alltid ha en endelig størrelse. En array er typisk statisk og deklareres med en fast størrelse. En liste er typisk dynamisk, og kan vokse og avta under programmets gang, men den vil alltid ha en ende som vi er nødt til å teste for når vi opererer på listen. En strøm er typisk uendelig og Det finnes også endelige strømmer, vi trenger aldri å teste for om strømmen er slutt. men det er en annen sak. 7 8

3 concurrency To regneprosesser kan utføres samtidig uten på noen måte å affektere hverandre, men hvis to regneprosesser opererer på samme foranderlige objekt, kreves tilstandsprogrammering (se side 11). Læreboka har et avsnitt om dette. Visse funksjonelle språk har mekanismer for å håndtere dette funksjonelt, eller mer presist innenfor det funksjonelle paradigmet. Alle de ovennevnte begrepene er nevnt i vår lærebok SICP, Structure and Interpretation of Computer Programs, og vi kan vel si at den grundigste definisjonen av funksjonell programmering har vist seg å være nettop SICP. (Men SICP sier ikke alt om funksjonell programmering, og den dreier seg ikke bare om funksjonell programmering). Dette tas ikke opp i INF Programmeringsparadigmer I eksplorativ (undersøkende) programmereing versus - imperativ / sekvensiell programmering med tilstandsendringer - funksjonell / eksplorativ programmering uten tilstandsendringer definerer vi en statisk verden vha. predikater, funksjoner og regler, Imperativ programmering er karakterisert ved verditilordning, dvs. at programmets objekter tall, strenger og sammensatte objekter får sine verdier /attributter endret under programmets gang. Hver verditilordning innebærer en endring i programmets tilstand. Hver beregning er bestemt av forutgående tilstandendringer. og bruker så disse til å undersøke verden uten å endrer verden våre undersøkelser har ingen bieffekter (side-effects) Kall på en gitt prosedyre gir alltid samme resultat med samme argumenter, uavhengig av når kallet utføres i forhold til andre prosedyrekall, dvs. Sekvensen i utførelsen av de ulike delene av en beregning er uten betydning. Sekvensen i utførelsen av instruksjoner og operasjoner er av betydning

4 Funksjoner og prosedyrer Vi sier tildels det samme om prosedyrer som om funksjoner: En prosedyre tar ett eller flere argumenter og gir en verdi. En prosedyre skal alltid gi samme resultat med samme argumenter. Men en prosedyre må også være effektiv, i den forstand at den utfører en beregning og returnerer et konkret resultat når den kalles. Implementasjon Gitt en funksjon f(x) og en prosedyre p(x), slik at for alle x så er returverdien fra kallet p(x) = f(x). Da sier vi at p er en implementasjon av f. En implementasjon gjøres i henhold til en fremgangsmåte en algoritme. Gitt en prosedyre q med en annen kropp en p, men slik at for alle x så er returverdien fra kallet q(x) = f(x). Da er p og q forskjellige prosedyrer, men begge er implementasjoner av f Noen høynivåspråk FORTRAN 1958 primitivt, ustrukturert og rendyrket imperativt LISP 1959 primært funksjonelt, men også med imperative mekanismer ALGOL 1960 strukturert overveiende imperativt SIMULA PASCAL 1962 ALGOL-basert alle objekorienterte språks mor (Dahl og Nygård) 1970 enkelt, pedagogisk, rent, strengt, imperativt C 1972 funksjonelt / instruksjonelt maskinnært og overbærende (tillater det meste) C SIMULA-inspirert videreutvikling av C, men langt strengere enn C. Java 1995 arkitekturuavhengig, biblioteksbasert, syntaktisk viderutviking av C++ HASKELL 1990 et rent funksjonelt språk. SCHEME er både - funksjonelt, - imperativt og - objektorientert. men ikke på samme måte som bl.a. JAVA, der objektorienteringen er integrert i språkets syntaks Programutførelse interpretering vs. kompilering + eksekvering Klassiske programmeringsomgivelse - kildekodeeditor - kompilator og eventuelt linker og bygger - operativsystemet. Kompilatoren - sjekker det skrevne programmets syntaks og indre konsistens, og når alt er ok, - oversetter kildekodeversjonen av programmet til en maskinkodeversjon. Linkeren - sjekker at alle variabler og kodesekvenser er på plass, f.eks. at en prosedyre som kalles både er deklarert og definert. Byggeren - bygger disse sammen til et helhetlig program. Operativsystemet - kjører programmet ved å overlate kontrollen av maskinen til programmets entry point typisk første setning i hovedprogrammet (main), i programmer skrevet i imperative språk som Java og C

5 Moderne programmeringsomgivelser relativt til perioden fra 1950-tallet til et stykke inn på 1980-tallet IDE Integrated Development Envirnoment - integererer kompilering, lenking og bygging - formidle mellom operativsystemet og programmet ved å legge inn ad hoc entry-points for utførleser av deler av programmet - inspisere programmets tilstander på angitt break-points Interpretere - Leser og tolker kildekoden og utfører det intenderte programmet i én og samme sveip. - Er typisk ikke bundet til hovedprogrammets entry-point. I Scheme kan en hvilken som helst funksjon sendes direkte til interpreteren. - Eventuelle syntaksfeil og inkonsistenser rapporteres når de dukker opp (og fører da selsvagt til kjøreavbrudd). - mm Effektivitet Forhåndskompilering skal i prinsippet være mer effektivt enn interpretering, men med dagens prosessorhastigheter her dette mindre betydning, og med JIT-kompilering (se neste side) er forskjellen nærmest opphevet. Racket, som er den Scheme-implementasjonen som anbefales i INF2810, har en JIT-kompilator, og jeg tror de fleste vil oppleve denne som mer enn rask nok. I tillegg gir Racket mulighet for forhåndskompilering, fra kildekode til stand-alone applikasjoner. Just In Time (fra noe bearbeidet) In computing, just-in-time compilation (JIT), also known as dynamic translation, is a method to improve the runtime performance of computer programs. Traditionally, computer programs had two modes of runtime operation, - interpreted, or - static (ahead-of-time) compilation.... JIT compilers represent a hybrid approach, - with translation occurring continuously, as with interpreters, but - with caching of translated code to minimize performance degradation.... Several modern runtime environments, such as Microsoft's.NET Framework and most implementations of Java, rely on JIT compilation for high-speed code execution

6 Scheme er i utgangspunket et svært enkelt språk, med syntaks for bindinger (av variabler til verdier), bl.a. vha. definisjoner, spesialformer for bl.a. tester og valg: if, and, or, etc, og prosedyreobjekter: lambda prosedyrekall (p a 1...) der p er en prosedyre og a 1... er argumentene til p. primitiver, dvs. forhåndsdefinerte prosedyrer som +, /,=, max, abs, etc. Scheme har vært revidert flere ganger siden den første standarden ble definert i Revisjonene opp til og med R 5 RS Revised 5 Report on the Algorithmic Language Scheme svarer i det store og hele til det vi kan kalle SICP-Scheme. I PLT-Scheme (nå omdøpt til Racket), fra og med versjon 4, er det gjort en endring som gjør det umulig å endre strukturer som er bygget opp av lister. Her skiller PLT-Scheme seg fra SICP-Scheme. Det er mere ved Scheme enn dette, men dette er essensen. Alle uttrykk i Scheme, bortsett fra slikt som tall og tegn, er parenteser. Kodingen dreier seg dermed mye om å matche venstre og høyreparenteser, men her får man god hjelp av editoren i alle fall hvis man bruker DrRacket. Mer om det i siste halvdel av kurset. R 6 RS, som ble vedtatt i 2007, har med noen flere standard mekanismer, noen semantiske endringer og et større prosedyrebibliotek Grensesnitt / Programmeringsomgivelser (i DrRacket) REPL the Read-Eval-Print-Loop (les input fra bruker, evaluer input, skriv resultatet til skjermen) I REPL skrives input og output på separate linjer Her vises de på samme linje av plasshensyn > > (+ 2 2) 4 > (2 + 2) procedure application: expected procedure, given: 2; arguments were: #<primitive:+> 2 > (substring "hallo" 1 3) "al" > (/ (string->number "56") 3) 18 2/3 > (exact->inexact (/ 56 3)) > (list 1 2 3) (1 2 3) > (car (list 1 2 3)) 1 > (cdr (list 1 2 3)) (2 3) > (= (+ 2 2) 4) #t > (= (+ 2 2) 5) #f > (= 1 "yo") =: expects type <number> as 2nd argument, given: yo; other arguments were: 1 > (equal? 1 "yo") #f > (equal? 'yo (car '(yo doh doodle))) #t > (define en-to-tre (list 1 2 3)) > en-to-tre (1 2 3) > + #<primitive:+> > (apply + en-to-tre)

7 Uttrykk (Expressions) Selvevaluerende atomære uttrykk > 324 ; number nærmere bestemt integer 324 > 3.24 ; number nærmere bestemt real 3.24 > 3/24 ; number nærmere bestemt rational 1/8 > #\A ; char(acter) #A > #t ; boolean #t > "hallo" ; string "hallo" Literale (bokstavelige) uttrykk (latin: litera, engelsk letter, norsk: bokstav) Alle uttrykkene over er literale, men det er også følgende > 'hei ; quoted symbol hei i motsetning til dette: > hei reference to undefined identifier: hei Sammensatte uttrykk (Compositions) operasjoner > (+ 2 3) ; bruk av prosedyren + 5 > (- 2 3) ; bruk av prosedyren - -1 > (* 2 3 4) ; bruk av prosedyren * 24 > (/ 5 2) ; bruk av prosedyren / Mer om quotations siden. Her nøyer vi oss med å konstatere at vi ved hjelp aven innledende enkel apostrof kan innføre bokstavelige uttrykk ustraffet med flere Syntaks Prosedyrekall generelt: (<prosedyre> <ingen, én eller flere argumenter>) Prefix Alt er prefikset også bruk av operatorer (regneuttrykk) Og strengt tatt er det ikke noe skille mellom operatorer og prosedyrer. (abs (- 5 8)) 3 Infix Pascal, C, C++, Java, m.m. Mest vanlig for aritmetiske og logiske operatorer. kombinert med prefixede funksjonskall (prosedyrekall). abs(5-8) 3 En liten digresjon for de som måtte lure på om følgende var mulig: Postix Bl.a. i FORTH et stakk-orientert programmeringsspråk abs 3 Her trenger vi ikke parenteser, gitt at operatorenes ariteteter (ant. operander) er fixert / * 6 virker bare hvis alle tre operatorer er strengt binære. Vi tenker oss operandene på en stakk med siste operand øverst opererer på de to øverste, 5 og 4, og legger resultatet 9 tilbake på stakken / opererer på de to som nå er øverst, 9 og 3, og legger resultatet 3 tilbake på stakken. 3 2 * opererer på de to som nå er igjen, 3 og 2, og legger resultatet 6 tilbake på stakken. 6 Tilsvarende i prefix: (* (/ (+ 5 4) 3) 2) 6 Men her kunne vi hatt: (* (/ ( ) 3) 2) 6 Som i postfix tilsvares av: / *

8 Prefix muliggjør vilkårlig mange argumenter ( ) 10 ( ) -4 ; NB! (- (- 1 2) 3) = (- -1 3) = -4 = (- 1 (+ 2 3)) ; ikke (- 1 (- 2 3)) = (- 1 (- 1)) = 0 (* 2 3 5) 30 (/ ) 6 ; NB! = (/ (/ 84 2) 7) = (/ 42 7) = 6 = (/ 84 (* 2 7)) ; ikke (/ 84 (/ 2 7)) = (/ 84 2/7)) = 294 Prefix muliggjør nøstede kombinasjoner (med det gjør selvsagt også infix) (+ (* 3 5) (- 10 6)) 19 (+ (* 3 (+ (* 2 4) (+ 3 5))) (+ (- 10 7) 6)) 57 De fleste Scheme-editorer har innrykksmekanismer for bedre leselighet (+ (* 3 (+ (* 2 4) (+ 3 5))) (+ (- 10 7) 6)) Innrykkene fremkommer automatisk ved trykk på Enter (også vha TAB). 29 Lisps parentesbaserte prefixnotasjon overflødiggjør regler for operatorpresedens Ser vi bort fra slike regler, gir uttrykket / 3 * 4-5 følgende 14 tolkningsmuligheter: Infix Prefix (3 + (8 / (2 * (3 2)))) (+ 3 (/ 8 (* 2 (- 3 2)))) 8 (3 + (8 / ((2 * 3) 2))) (+ 3 (/ 8 (- (* 2 3) 2))) 6 (3 + ((8 / 2) * (3 2))) (+ 3 (* (/ 8 2) (- 3 2))) 8 (3 + ((8 / (2 * 3)) 2)) (+ 3 (- (/ 8 (* 2 3)) 2)) 10/3 (3 + (((8 / 2) * 3) 2)) (+ 3 (- (* (/ 8 2) 3) 2)) 14 ((3 + 8) / (2 * (3 2))) (/ (+ 3 8) (* 2 (- 3 2))) 6 ((3 + 8) / ((2 * 3) 2)) (/ (+ 3 8) (- (* 2 3) 2)) 3 ((3 + (8 / 2)) * (3 2)) (* (+ 3 (/ 8 2)) (- 3 2)) 8 (((3 + 8) / 2) * (3 2)) (* (/ (+ 3 8) 2) (- 3 2)) 6 ((3 + (8 / (2 * 3))) 2) (- (+ 3 (/ 8 (* 2 3))) 2) 10/3 ((3 + ((8 / 2) * 3)) 2) (- (+ 3 (* (/ 8 2) 3)) 2) 14 (((3 + 8) / (2 * 3)) 2) (- (/ (+ 3 8) (* 2 3)) 2) 0 (((3 + (8 / 2)) * 3) 2) (- (* (+ 3 (/ 8 2)) 3) 2) 22 ((((3 + 8) / 2) * 3) 2) (- (* (/ (+ 3 8) 2) 3) 2) Utfordrende Øvelse (Ukeoppgave senere i kurset) Skriv et Scheme-program for beregning av antall mulige parenteskombinasjoner generelt for et gitt antall operander, når vi ser bort fra operatorpresedenser. (Merk at det siste kravet innebærer at alle operasjoner må være binære.) operander kombinasjoner 1 1: (o 1 ) 2 1: (o 1 o 2 ) 3 2: (o 1 (o 2 o 3 )), ((o 1 o 2 ) o 3 ) 4 5: (o 1 (o 2 (o 3 o 4 )), (o 1 ((o 2 o 3 ) o 4 )), ((o 1 o 2 ) (o 3 o 4 )), ((o 1 (o 2 o 3 )) o 4 ), (((o 1 o 2 ) o 3 ) o 4 ) 5 14: (o 1 (o 2 (o 3 (o 4 o 5 )))) ((((o 1 o 2 ) o 3 ) o 4 ) o 5 ) Navn (identifiers) Variabler > (define x 5) > x 5 Variabeldefinering generelt: (define <variabel> <verdi>) > (define pi ) > (define radius 10) > (* pi radius) > (define gyldne-snitt (/ (+ 1 (sqrt 5)) 2)) ; se SICP s.38 > gyldne-snitt

9 Prosedyrer > (define (navle-høyde høyde) (/ høyde gyldne-snitt)) > navle-høyde #<procedure:navle-høyde> > (navle-høyde 185) Prosedyredefinering generelt: (define (<prosedyrenavn> <formelle parametre>) <prosedyrekopp>) > (define (gjennomsnitt x y ) (/ (+ x y) 2)) Prosedyrekall / -bruk / -anvendelse (application) generelt: (<prosedyrenavn> <aktuelle parametre>) > (gjennomsnitt 2 3 ) > (gjennomsnitt ) 2.5 Omgivelse (Environment) Tabell(er) med kobling mellom navn og verdier (mer om dette siden) NB! dette dreier seg om - omgivelsen til en prosedyre under programutførelsen som er noe helt annet enn - en programmeringsomgivelse. I vanlig norsk snakker vi stort sett om omgivelser i flertall, mens man i engelsk snakker om environment i entall Eks: nye omgivelser a new environment Nå vi snakker om programmering velger vi imidlertid den engelske formen, for tydelighets skyld, f.eks. når vi snakker om den innerste omgivelsen i et nøste eller hierarki av omgivelser. Kommentarer legges sist på linjen eller på en linje for seg selv og skilles fra koden med et semikolon. I tråd med SICP vil vi heretter bruke termen argument i stedet for actual parameter Definisjoner, binding og leksikalsk statisk skop > (define (f x y) ; f defineres globalt, mens x og y (* (/ x y) 2)) ; bare defineres lokalt i kroppen til f Vi sier at f har globalt skop (gresk skopos: mål (det vi sikter eller ser mot, fra skopein: se)), mens x og y har lokalt skop. Dette kalles leksikalsk skop fordi programmets leksikalske elementer (identifikatorene) er synlige innenfor de områder der de er definert. Det kalles statisk skop fordi et gitt navn i en gitt omgivelse alltid referer til en og samme gitte variabel. I dynamisk skop har hver variabel en stack av bindinger knyttet til lokale run-time lokasjoner. Dette har noen fortrinn og et hav av plagsomme ulemper. 35 > (define (f x y) ; f defineres globalt, mens x og y (* (/ x y) 2)) ; bare defineres lokalt i kroppen til f > (f 9 3) ; x og y bindes hhv. til verdiene 9 og 3 ; i kroppen til f under dennes utførelse 6 > (+ x 1) reference to undefined identifier: x > (define x 6) ; x defineres globalt og bindes til verdien 6 > x ; og kan nå også brukes globalt 6 > (f x x) ; x og y if f bindes hver for seg til den verdien ; den globalt definerte x har, dvs. 6 2 > (define y 3) ; y defineres globalt og bindes til verdien 3 > (define (g y) ; g defineres globalt og y defineres lokalt. (* (/ x y) 2)) ; x brukes i henhold til sin globale definisjon, men ; den lokale y stenger for utsynet til den globale y > (g 3) ; y bindes til verdien 3 i f under dennes utførelse ; mens x stadig har verdien

10 Primitiver En primitiv er en prosedyre som er definert i språket Scheme, og som skal være med i alle implementasjoner av Scheme. Fra R 5 RS (Revised 5 Report on the Algorithmic Language Scheme): [ ] Scheme's built-in procedures. The initial (or ``top level'') Scheme environment starts out with a number of variables bound to locations containing useful values, most of which are primitive procedures that manipulate data. For example, the variable abs is bound to (a location initially containing) a procedure of one argument that computes the absolute value of a number, and the variable + is bound to a procedure that computes sums. I REPL gjengis verdien til en primitiv, f.eks. +, slik: #<primitive:+> Evaluering av et sammensatt uttrykk Evalueringsregel for sammensatte uttrykk 1. Evaluer utrrykkets deluttrykk! 2. Bruk den prosedyren som er verdien til første ("venstreste") deluttrykk på de argumentene som fremkommer ved evalueringen av de øvrige deluttrykkene! Uttrykket "er verdien til" har en spesiell signifikans i forhold til punkt 1. Poenget er at alt evalueres, etter bestemte regler, til en eller annen verdi. Eks: (+ 2 3) 1. Her er 2 og 3 selvevaluerende, dvs. de er sine egne verdier, mens + er navnet på en prosedyre, og dermed gir evalueringen av + denne prosedyren som første verdi i listen. 2. Anvend denne prosedyren på argumentene 2 og 3 hvilket i dette tilfellet vil si: legg sammen 2 og Evalueringsregelen er rekursiv. Ved evalueringen av det sammensatte utrrykket (+ (* 2 3) 4) kommer evalueringsregelen til anvendelse på seg selv i forhold til deluttrykket (* 2 3) Evaluer deluttrykkene Evaluer deluttrykkene i deluttrykkene Evaluer de atomære deluttrykkene Her er ett av eksemplene over (+ (* 3 (+ (* 2 4) (+ 3 5))) (+ (- 10 7) 6)) Her med linjeskift og innrykk (+ (* 3 (+ (* 2 4) (+ 3 5))) (+ (- 10 7) 6)) 39 Vi roterer 90, speilvender, fjerner parentesene, og følger evalueringen på de ulike nivåene. + * * * * NB! Dette viser ikke rekkefølgen i evalueringen. Den er slik: (a) + ==> #<primitive:+>, (b) * ==> #<primitive:*>, (c) 3 ==> 3, (d) + ==> #<primitive:+>, (e) * ==> #<primitive:*>, (f) 2 ==> 2, (g) 4 ==> 4, (h) (* 2 4) ==> 8, (i) + ==> #<primitive:+>, (j) 3 ==> 3, (k) 5 ==> 5, (l) (+ 3 5) ==> 8, (m) (+ 8 8) ==> 16, (n) (* 3 16) ==> 48, (o) + ==> #<primitive:+>, (p) ==> #<primitive: >, (q) 10 ==> 10, (r) 7==> 7, (s) (- 10 7) ==> 3, (t) (+ 3 6) ==> 9, (u) (+ 48 9) ==>

11 Her er en annen tre-representasjon av evalueringen der hvert subtre tilsvarer en parentes, og der verdiene på rotnodene angir de evaluerte verdiene. Definisjoner, kall og utførelse (define (<prosedyrenavn> <formelle parametre>) <prosedyrekopp>) Prosedyrenavnet med kobling til parameterne og prosedyrekroppen legges i den globale omgivelsen eller omgivelsene bestående av den blokken der prosedyredefinisjonen ligger. Ved et kall på prosedyren blir formelle paramterene navn bundet til de aktuelle argumentene i de lokale omgivelsene som opprettes for utførelsen av kallet. Evalueringen skjer fra roten og nedover og innsetting av verdiene fra bladene og oppover Kroppen er et uttrykk som evaluere til det resultatet prosedyren skal returnere, når argumentene settes inn for de formelle parametrene, el. m.a.o. når variablene i prosedyrekroppen bindes til argumentene Substitusjonsmodellen (define (plus-en n) (+ n 1)) kvadratsum evalueres umiddelbart til #<procedure:kvadratsum>, dvs. prosedyren kvadratsum. (define (dobbel n) (* n 2)) (define (kvadrat x) (* x x) (define (kvadratsum x y) (+ (kvadrat x) (kvadrat y))) (define (f a) (kvadratsum (plus-en a) (dobbel a))) Vi følger evalueringen av kallet (f 5) Kroppen til f er et sammensatt uttrykk med tre deler, Delene evalueres én for én Vi går her ut fra at de evalueres fra venstre, men dette er ikke et krav i R 5 RS, og rekkefølgen og resultatene settes inn i uttrykket, dvs. i evalueringen kunne like gjerne ha vært den motsatte. Slik er det imidlertid ikke i tilstandsbasert programmering. De opprinnelige delene substitures med resultatene av deres evalueringer. Det sammensatte uttrykkket (plus-en 5) evalueres på samme måte: plus-en evalueres umiddelbart til #<procedure:plus-en>, 5 evalueres umiddelbart til seg selv, og vi går inn i kroppen til plus-en: (+ 5 1) Her evalueres alle leddene umiddelbart, til henholdsvis #<primitive:+>, 5 og 1. og kallet på + utføres med 5 og 1 som argumenter og 6 som resultat. Nå kan uttrykket (plus-en 5) substitueres med 6 i kallet på kvadratsum. (uttrykket dobbel a) evalueres på samme måte, med 10 som resultat

12 Dermed er evalueringen av alle leddene i kroppen til f utført, med uttrykket (#<procedure:kvadratsum> 6 10) som resultat, og vi går inn i kroppen til kvadratsum der x bindes til 6 og y bindes til 10. Dette gir det sammensatte uttrykket (+ (kvadrat 6) (kvadrat 10)) De tre leddene evalueres på tilsvarende måte som over, og vi får uttrykket (#<primitive:+> ) som evalueres med 136 som resultat. 136 settes inn i kroppen til f, og f er dermed ferdig evaluert og returner Bruk f (f 5) Substituer prosedyrenavn f med kropp: (kvadratsum (plus-en a) (dobbel a)) Substituer parameter a med argument 5: (kvadratsum (plus-en 5) (dobbel 5)) Substituer prosedyrenavn plus-en med kropp: (kvadratsum (+ n 1) (dobbel 5)) Substituer parameter n med argument 5: (kvadratsum (+ 5 1) (dobbel 5)) Substituerprosedyrenavn + primitiv prosedyre: (#<primitive:+> 5 1) Substituer bruk av + med resultatsum: (kvadratsum 6 (dobbel 5)) Substituer pros-navn dobbel med kropp: (kvadratsum 6 (* n 2)) Substituer parameter n med argument 5: (kvadratsum 6 (* 5 2)) Substituer bruk av primitiv * m. result.produkt: (kvadratsum 6 10) Substituer pros-navn kvadratsum m. kropp: (+ (kvadrat x) (kvadrat y)) Substituer parameter x med argument 6: (+ (kvadrat 6) (kvadrat y)) Substituer pros-navn kvadrat med kropp: (+ (* x x) (kvadrat y)) Substituer parameter x med argument 6: (+ (* 6 6) (kvadrat y)) Substituer bruk av primitiv * m. result.produkt: (+ 36 (kvadrat y)) Substituer parameter y med argument 10: (+ 36 (kvadrat 10)) Substituer pros-navn kvadrat med kropp: (+ 36 (* x x)) Substituer parameter x med argument 10: (+ 36 (* 10 10)) Substituer bruk av primitiv * m. result.produkt: ( ) Substituer bruk av primitiv + med result.sum: Evalueringsorden (define (kvadrat n) (* n n)) (define (double n) (+ n n)) Normal orden Sammensatte uttrykk evalueres ved at formen til eventuelle ikke-primitive deluttrykk reduseres til primitive former, Appliaktiv orden (som er det vi har sett så langt) før den endelige evalueringen utføres. Sammensatte uttrykk evalueres innefra og utover slik at resultatene av evalueringene av de innerste uttrykkene settes inn i de omkringliggende uttrykkene slik at disse kan evalueres osv. Til slutt vil alle deluttrykk i det ytterste uttrykket være regnet ut slik at dette evalueres. (double (kvadrat (double 2))) (double (kvadrat 4)) (double 16) (double (kavdrat (double 2))) (double (kvadrat (+ 2 2))) (double (* (+ 2 2) (+ 2 2))) (+ (* (+ 2 2) (+ 2 2)) (* (+ 2 2) (+ 2 2))) (+ (* 4 4) (* 4 4)) ( ) 32 Det kan se litt klønete ut her, fordi vi ender med å utføre de samme regnestykene flere ganger, men, som vi skal se senere i kurset, er normalordensevaluering et essentiell element i utsatt evaluering og dermed i strømmer som bl.a. gjør det mulig å behandle uendelig sekvenser. 48

13 Følgende gir feilmelding ved applikativ, men ikke ved normal evalueringsorden > (define (f a) "hallo") > (f (* 2 "hei")) Problemet er det umulige produktet av et tall og en streng som utgjør argumentet i kallet på f. Siden parameteren a ikke brukes i kroppen til f, vil det strengt tatt ikke være nødvendig å evaluer produktet, men dette får vi altså bare glede av ved normal evalueringsorden. Kondisjonaler og predikater / tester / booleske uttrykk Betingelsesuttrykket cond Absoluttverdien til et tall x x, hvis x > 0 x = 0, hvis x = 0 x, hvis x < 0 (define (abs x) (cond ((> x 0) x) ((= x 0) 0) ((< x 0) (- x)))) I Haskell, som er rent funksjonelt språk med utelukkende normalordens evaluering, gjøres noe lurt for å unngå dupliserte utregninger slik at språket blir brukelig i praksis, idet en regnestykke i en evaluering gjøres til et objekt som bare utføres én gang. Primitven (minus) med kun ett argument har tilsynelatende en annen semantikk enn den samme primitiven med flere argumenter, idet den første returnerer negasjonen av sitt argument. Men forskjellen forsvinner når vi setter inn identitetselementet som første argument. -1 (- 1) (- 0 1) Merk forskjellen mellom dette og (- 1 0), som evaluerer til Generelt (cond (<p 1> <e 1>) (<p 2> <e 2>)... (<p n> <e n>)) Det engelske ordet for parentesene etter cond er clauses. Vi kunne for eksempel kalle dem cond-ledd. Disse angir de enkeltvise betingelser og konsekventer, som til sammen angir hele cond-setningen. p står for predikat, mens e står for expression (uttrykk) Et predikat evaluerer alltid til én av de to booleske verdiene #t og #f. (Vi vil i denne teksten av og til skrive true og false som synonymer for disse.) Vi bruker termen predikat først og fremst om - funksjoner som tar ett argument og returnerer true eller false avhengig av om argumentet har en bestemt egenskap, og - funksjoner som tar to argumenter og returnerer true eller false avhengig av om argumentene står i en bestemt relasjon til hverandre. (number? 25) #t (number? "hei") #f (string=? "hei" "hallo") #f (> 5 2) #t Også booleske variabler kan sies å være predikater (argumentløse predikater). (define sant #t) Siden sant ikke tar argumenter, returnerer den alltid samme verdi, når definisjonssetningen først er utført

14 Ellers snakker vi like gjerne om tester og vi sier da at - en cond-clause består av en test fulgt av et annet uttrykk Evalueringen av et cond-uttrykk utføres slik at - hver enkelt test evalueres i tur og orden - inntil løpende test eventuelt evalueres til true, og - i så fall evalueres det etterfølgende uttrykket i den aktuelle clause og resultatet av dette blir også resulatet av hele cond-uttrykket. Hvis ingen av testene evaluerer til true, blir verdien til cond-uttrykket ubestemt. I Scheme returneres i slike tilfeller verdien #<void>. En typisk cond clause innholder en test og et etterfølgende uttrykk, men strengt tatt kan den inneholde testen alene, eller ett eller flere etterfølgende uttrykk. Uansett vil alle uttrykken i claus'en evalueres, og så vil resultatet av evalueringen av det siste uttrykket, som kan være testen, returneres. Dette kommer vi nærmere tilbake til. 53 Retur av en ubestemt verdi fra et cond-uttrykk gir ikke noe umiddelbart kjøreavbrudd, men en cond-setning som ikke er garantert å evaluere til en bestemt verdi, vil normalt representere en logisk brist i et program, som kan gi gale resultater eller kjøreavbrudd på et senere punkt. (define (dagnavn->dagnum dagnavn) (cond ((eq? dagnavn 'mandag) 1) ((eq? dagnavn 'tirsdag) 2) ((eq? dagnavn 'onsdag) 3) ((eq? dagnavn 'torsdag) 4) ((eq? dagnavn 'fredag) 5))) (define (hverdag? dagnavn) (< (dagnavn->dagnum dagnavn) 6)) > (hverdag? 'lørdag) <: expected argument of type <real number>; given #<void> Prosedyren hverdag? bruker prosedyren < for å sammenligne to tall. Siden ingen av cond-claus'ene i dagnavn->dagnum sjekker for 'lørdag, er returverdien derfra ubestemt, mens < krever to tallargumenter. 54 I alle andre tilfeller I cond-setningen over for beregning av absoluttverdien til x angis alle muligheter eksplisitt, men dermed er den siste testen overflødig i den forstand at dersom x hverken er større enn eller lik 0, så må x være mindre enn 0. For slike formål har vi nøkkelordet else (som kan oppfattes som et synonym for true). (define (abs x) (cond ((> x 0) x) ((= x 0) 0) (else (- x)))) Ett av to Nå er det heller ingen grunn til å skille mellom de tilfellene at x er større en 0 og at x er lik 0, siden det er verdien til x som skal returneres uansett. Vi kan uttrykke dette slik: (define (abs x) (cond ((>= x 0) x) (else (- x)))) Dette er en binær test idet den skiller mellom to tilfeller som til sammen dekker alle mulige. Valguttrykket if Siden binære tester er svært vanlige, har vi en egen konstruksjon for disse. (define (abs x) (if (>= x 0) x (- x))) Generelt: (if <test> <konsekvent> <alternativ>) Egentlig er det if som er den tilgrunnliggende formen, og cond, så vel som and og or (se under), er avledninger av denne 55 56

15 Spesialformene and og or og prosedyren not Det regner og det er onsdag (and det-regner det-er-onsdag) Det regner eller det er onsdag (or det-regner det-er-onsdag) Det regner, men det er ikke onsdag (and det-regner (not det-er-onsdag)) Det hverken regner eller er onsdag (and (not det-regner) (not det-er-onsdag))) (not (or det-regner det-er-onsdag)) Enten regner det eller så er det onsdag (and (or det-regner det-er-onsdag) (not (and det-regner det-er-onsdag))) x er et skuddår hvis x er delelig med 4 og x er ikke delelig med 100 eller x er delelig med 400. x er delelig med y hvis x / y er et heltall, hvilket vil si det samme som at x / y ikke gir noen rest. For rest-beregningen bruker vi Scheme-primitiven (remainder x y) ==> resten etter heltallsdelingen av x på y. Vi definerer delelighetspredikatet divisible? vha. remainder. (define (divisible? x y) (= 0 (remainder x y))) og vi kan så definerere skuddårspredikatet vha. divisible?. (define (skuddår? x) (and (divisible? x 4) (or (not (divisible? x 100)) (divisible? x 400)))) Alternativt: (define (skuddår? x) (or (divisible? x 400) (and (divisible? x 4) (not (divisible? x 100))))) Vi kan uttrykke det samme vha. betingelsesformen cond. (define (skuddår? x) (cond ((divisible? x 400)) ; hvis testen slår til, returners #t implisitt ((divisible? x 100) #f) ; her må vi returnere #f for å komme oss ut. ((divisible? x 4)) ; hvis testen slår til, returners #t implisitt (else #f))) Merk testrekkefølgen. Bytter vi om f.eks først og andre clause, får vi ikke fanget opp delelighet med 400. NB! Dette er et helt annet poeng enn det at et imperativt program er sekvensielt, dvs. at rekkefølgen i utførelsen av programmets prosedyrer kan ha betydning for sluttresultatet. Her er programutførelsen en sekvens av tilstander, gitt ved de foranderlige verdiene til programmets variabler, f.eks. slik at hvis prosedyren p endrer verdient til v og prosedyren q bruker v, så er resultatet av kallet på q bestemt av om p kalles før eller etter q. Siden både cond, and og or er avledninger av if, må det være mulig å uttrykke ovenstående vha. if alene (define (skuddår? x) (or (divisible? x 400) (and (divisible? x 4) (not (divisible? x 100))))) (define (skuddår? x) (cond ((divisible? x 400)) ; hvis testen slår til, returners #t implisitt ((divisible? x 100) #f) ; her må vi returnere #f for å komme oss ut. ((divisible? x 4)) ; hvis testen slår til, returners #t implisitt (else #f))) (define (skuddår? år) (if (divisible? år 4) (if (divisible? år 100) (if (divisible? år 400) #t ; delelig både på 4, 100 og 400 #f) ; delelig på 4 og 100, men ikke på 400 #t) ; delelig på 4, men ikke på 100 #f)) ; ikke delelig på

16 Månedslengder Vi kan bruke predikatet skuddår? til å beregne lengden til en gitt måned i et gitt år. (define (månedslengde m y) (cond ((or (= m 1) (= m 3) (= m 5) (= m 7) (= m 8) (= m 10) (= m 12)) 31) ((or (= m 4) (= m 6) (= m 9) (= m 11)) 30) ((skuddår? y) 29) (else 28))) Her er en versjon der vi tar hensyn til muligheten for ulovlige månedsverdier. (define (månedslengde m y) (cond ((or (= m 1) (= m 3) (= m 5) (= m 7) (= m 8) (= m 10) (= m 12)) 31) ((or (= m 4) (= m 6) (= m 9) (= m 11)) 30) ((= m 2) (if (skuddår? y) 29 28)) (else (error "månedslengde: ulovlig måned")))) For de som måtte være interessert Slå opp semestersiden for INF2810 R5RS under Ressurser og case i indeksen til R5RS. (define (månedslengde m y) (case m (( ) 31) (( ) 30) (else (if (skuddår? y) 29 28)))) Case forutsetter at alle de verdiene det testes for er distinkte