TDDC74 Lab 04 Muterbara strukturer, omgivningar 1 Översikt I den här laborationen kommer ni att lära er mer om: Tillstånd, och skillnader mellan ren funktionell programmering och imperativ. Skillnaden mellan att returnera ett värde och att visa ett värde. Procedurer som minns någon form av data. Lexical closures. 2 Värt att veta Laborationen berör kapitel 3 i kurslitteraturen. För mer läsning se även SICP+03 som finns på http://www.ida.liu.se/~tddc74/labbar/extra/ pram-sicp03-2017.pdf När ni är klara med denna labb, fortsätt med laboration 5 så snart ni har möjlighet. 2.1 Filer Börja med att kopiera filerna från ~TDDC74/lab/lab4 till din labb 4-katalog (~/kurs/tddc74/lab4). 1
Uppgift 1 ----------------------------------------------------------------------- Förklara skillnaden mellan att en procedur returnerar ett värde och att en procedur skriver ut ett värde. Förklara även vad som händer, och varför utdata ser ut som det gör, för vart och ett av stegen nedan (efter define-uttrycken) för er labbassistent, antingen på plats eller i kodkommentar: >(define (foo bar) bar) > (define (bar foo) (printf "~a~n" foo)) > (+ (foo 3) 4)???? > (bar 3) > (+ (bar 3) 4)???? > (display (bar 3)) ;; skriv ut returvärdet Uppgift 2 ----------------------------------------------------------------------- Implementera en egen variant av primitiven for-each. Er implementation, for-each-element, ska ta in en procedur och en lista som argument. Den ska sedan köra sedan proceduren på varje element (på topp-nivån). Till skillnad från map samlar for-each inte upp resultaten. Det enda vi är intresserade av är sidoeffekten. > (for-each-element (lambda (element) (printf "Nuvarande element: ~a~n" element)) (1 2 foo bar 3)) Nuvarande element: 1 Nuvarande element: 2 Nuvarande element: foo Nuvarande element: bar Nuvarande element: 3 > (display (for-each-element (lambda (element) 2
(* element 100)) (1))) #<void> Notera att vi inte får tillbaka något från for-each-element. Vi applicerar (kör) funktionen vi skickar med, vi multiplicerar 1*100=100, men vi gör inget med resultatet. Vi kan såklart använda den för att uppdatera värden: > (let ([sum 0]) (for-each-element (lambda (num) (set! sum (+ sum num))) (1 2 3 4 5)) sum) 15 Det vill säga, skapa tillfälligt en bindning sum, uppdatera den ett antal gånger, returnera värdet i slutet. Uppgift 3 ----------------------------------------------------------------------- I denna uppgift ska vi börja utforska lexical closures, där vi knyter samman en procedur med en omgivning (och därmed indirekt med en uppsättning bindningar). På så vis kan man få procedurer som minns data. Skriv en procedur count-calls som returnerar antalet gånger den har blivit anropad. Detta ska göras med en intern räknare. Ni får alltså inte ha en global räknare, något i stil med (define *counter* 0). Proceduren ska också kunna nollställa sin räknare och kontrollera hur många gånger den har blivit anropad utan att den räknas upp. Alltså, om count-calls anropas med symbolen how-many-calls ska räknarens värde returneras. Om anropet görs med symbolen reset ska räknaren nollställas. > (count-calls how-many-calls) 3 > (count-calls how-many-calls) 3
4 > (count-calls reset) > (count-calls how-many-calls) 0 > (count-calls how-many-calls) 1 Notera att antalet argument som count-calls anropas med varierar 1. Titta i SICP+03 eller i annat material på kurshemsidan om ni inte är säkra på hur ni ska börja implementera proceduren. Uppgift 4 ----------------------------------------------------------------------- Det kan ibland vara intressant att veta ungefär hur många gånger en procedur anropas, för att se om den skalar väl. Mer allmänt kan det vara intressant att paketera procedurer på sätt som förändrar hur man anropar dem, kontrollerar att indata är korrekt, eller gör någon annan beräkning. I denna övning ska ni implementera en procedur make-monitored. Den ska som indata ta en procedur fn, och som utdata returnera en procedur som har en intern räknare. Varje gång den nya versionen av funktionen anropas, ska fn anropas, och räknaren räknas upp. Precis som i en tidigare uppgift ska man även kunna anropa den returnerade proceduren med symbolerna how-many-calls och reset. Vid alla andra argument ska fn anropas med övriga argument samt att räknaren ska stegas upp. I denna uppgift är apply mycket lämplig att använda. apply tar in en procedur och en lista och applicerar (kör) sedan proceduren med alla argument i listan. Följande två anrop är alltså desamma: > (apply max (1 2 3 4 5)) 5 > (max 1 2 3 4 5) 5 Så här ska make-monitored fungera: > (define monitored-max (make-monitored max)) > (monitored-max 1 2 3 4 1 5 6) 1 Lästips: https://docs.racket-lang.org/guide/lambda.html 4
6 > (max 10 20 30) 30 > (monitored-max how-many-calls) 1 > (monitored-max reset) > (monitored-max how-many-calls) 0 Vi kan också göra en helt annan monitored -procedur. Notera att den får en helt egen räknare. > (define fac (make-monitored (lambda (num) (if (zero? num) 1 (* num (fac (- num 1))))))) > (fac how-many-calls) 0 > (fac 3) 6 > (fac how-many-calls) 4 > (monitored-max how-many-calls) 0 Uppgift 5 ----------------------------------------------------------------------- En rekursiv procedur med iterativ processlösningsmodell (tänk sum-iter) kan enkelt transformeras till en iterativ procedur genom att utnyttja en enkel loop-procedur utan argument. Istället för att passa med nya versioner av gamla värden (med rekursiva anrop som (fak (+ n 1) (+ acc n))), uppdaterar man dem med (till exempel med set!). Er uppgift är att översätta en enkel rekusiv procedur till detta mönster. Antag att vi har följande rekursiva procedur som går genom en lista: (define (rev lst) (define (rev-iter lst res) 5
(if (null? lst) res (rev-iter (cdr lst) (cons (car lst) res)))) (rev-iter lst ())) Definiera en ny variant genom att skriva er kod på angivna platser: (define (rev lst) (let ([res ()]) (define (loop) (cond [(null? lst) <er kod> ] [else <ngn kod> (loop)])) (loop))) 3 Muterbara data, pekarändringar När vi tidigare har ändrat på data, har vi egentligen tagit gamla namn och ändrat vad de är knutna till. Ta till exempel detta kodstycke: (define *var* (mcons 1 2)) (set! *var* (mcons 1 x)) Först säger vi att det-som-kallas-*var* ska vara (det muterbara) paret (1. 2). Sedan säger vi att det som kallas *var* ska vara paret (1. x). Rent tekniskt ändrar vi aldrig något inuti paret (1. 2). Det vi gör på set!- raden är att skapa ett helt nytt (nästan likadant) par, och säga att namnet *var* ska peka på det. Eftersom det gamla paret inte används längre, städas det bort. I denna uppgift kommer vi att stöta på en muterbar datatyp, en där vi kan ändra i själva innehållet. Uppgift 6 ------------------------------------------------------------------------ Öppna filen pram-la04-mut.rkt som ni kopierade i början av labben 2. Kör 2 Den finns annars i TDDC74/lab/lab4/pram-la04-mut.rkt 6
uttrycken och förklara vad som händer. Vad kommer att skrivas i parenteser som värdet på start? Rita även låd-och-pekar diagram för att illustrera hur cons-cellerna är uppbyggda och vilka pekare som ändras. Gör inte kopior av cons-cellerna utan visa bara vilka pekare som har ändrats. 4 Inlämning Även för denna laboration finns en färdig uppsättning första tester att köra. Kopiera autotest-la04.rkt från TDDC74/lab/lab4 till samma katalog som filen ni skriver i, uppdatera filens require-rad, och skriv följande kod i slutet av er fil i Dr. Racket: (provide (all-defined-out)). Kör sedan autotest-la04.rkt. Får ni ett fel så läs vad felet säger! Det kan även vara intressant att ta en titt på hur autotest-filen ser ut inuti. 7
Appendix A Nya tillåtna primitiver: apply when void begin unless set! display newline Länktips: https://docs.racket-lang.org. 8