Helaas is de tweede toets veel slechter gemaakt dan we hadden verwacht. Ik geef hier nog wat commentaar naar aanleiding van het nakijken. Indien iemand uit kan leggen waar bij hem of haar aan schort (en wat we daaraan kunnen doen), dan wordt een reactie op prijs gesteld. Een uitwerking staat al gegeven in de tekst van het tentamen.

1

De meeste mensen hadden dit goed. Dit is mijns inziens ook wel noodzakelijk.

2

Dit was de moeilijkste multiple-choice vraag, en is ook door heel veel mensen fout beantwoord.

Zowel foldl als foldr bouwen het resultaat eerst helemaal als expressie op, om dat aan het eind pas het resultaat te gaan berekenen; foldl doet dit in een accumulerende parameter. Zie de plaatjes in het dictaat op pagina 159/160. We hebben op het college ook de foldl' behandeld, die het genoemde bezwaar niet heeft (zie pagina 161).

Antwoord (b) was het gezochte antwoord. Kijk eens naar:

id = foldr (:) [] 
ones = 1 :ones
stapvoorstap = id ones

Hier wordt van de waarde stapvoorstap alleen maar dat stuk van zijn oneindige resultaat berekend waar om gevraagd wordt.

Antwoord (c) is onjuist. Als je een zoekboom ongelukkig opbouwt hangt hij helemaal scheef, en is dan de facto isomorph met een lijst. De extra vergelijkingen kunnen zoeken dan zelfs langzamer maken.

Antwoord (d) is een volslagen onzin antwoord. Waarom zou de associativiteit van functie compositie afhangen van de associativiteit van lijst concatenatie? Er geldt gewoon:

f . (g. h) $ x = f ((g.h) x) = f (g (h x) = (f.g) (h x) = (f.g) . h $ x

3

Dit hadden veel mensen fout. Bedenk dat het zetten van een lijst attributen in wxHaskell in een keer kan. We geven dan een lijst met waardes aan; alle elementen van die lijst moeten hetzelfde type hebben, en kunnen dus niet van het type attribuut (a) afhangen. Dat leert ons dat alternatieven (c) en (d) niet waar kunnen zijn. Bij het gebruik van de := operator staat links het attribuut en rechts zijn waarde, dus alternatief (b).

We hadden gedacht dat dit een gemakkelijke vraag was voor iedereen die het artikel over wxHaskell heeft gelezen (nog niet eens bestudeerd), en een beetje had begrepen hoe de typering daarin werkt. Ook het zelf maken van het praktikum zou hierbij geholpen moeten hebben; immers, bij het maken van fouten komen deze zaken naar boven in de foutmeldingen.

4

Ook dit was een teleurstelling. Het type van een parser is [a] -> [(b, [a])], en het type vertelt ons dus dat hier altijd een lijst uit komt. Dit kan natuurlijk de lege lijst zijn, maar we spreken hier wel degelijk van de list of successes methode. Alteratief (b) verwijst direct naar opgave 8.11, en de laatste twee zijn evident onjuist voor wie de begrippen prioriteit en associativiteit kent, en gekeken heeft hoe de combinators werken.

5

5a

De meeste mensen hadden hier wel iets, alhoewel het soms voor de helleport weg moest komen, met veel indiceringen, deletes enz. Deze opgave heeft bij het laatste oefenwerkcollege nog weer op het bord gestaan. Onze functie splits werkt ook als er dubbele elementen in de lijst staan.

5b

Deze som was om het verschil te maken tussen een 9.5 en een 10. Heb je hier iets wat in de buurt komt dan krijg je hier een half punt voor en als het bijna goed is een heel. De meeste mensen hadden hier niets.

6

Heel veel mensen beginnen hier met:

lenght. concat []

en ik begrijp wat hier wordt bedoeld, maar het is strikt genomen wel fout, want er dienen haakjes om de functieapplicatie te staan:

(lenght. concat) []

Opvallend was dat veel mensen begonnen met:

lenght. concat [[]]

hetgeen natuurlijk niet de juiste manier is om een dergelijk inductiebewijs aan te pakken. Ik ben van mening dat deze vraag eigenlijk een heel gemakkelijke is, en samen met 3 uit 4 voor de multiple-choice sowieso tot een 5 zou moeten kunnen leiden voor deze toets, en tot een 6 als je ook 5a kunt maken.

6

Op zijn hoogst 20% van de mensen had hier iets, maar de mensen die iets hadden hadden het wel vaak (ongeveer) goed. Vaak is de conditie bij de instance declaraties vergeten:

instance Countable a => Countable (Node a) where ...

Opvallend vaak stonden er geen haakjes om Node a, en ook het alternatief voor Single a kreeg nog wel eens de waarde 1.

Algemene opmerkingen

het zetten van haakjes is nog steeds heel erg moeilijk
het definiëren van patronen gaat nog veel mensen slecht af

-- DoaitseSwierstra - 23 Apr 2008