Nüüd kodutööde kohta. Meil on siin üsna testipõhine lähenemine: tahame arendada just see oskus, et te saaks meie testide põhjal aru, mis võõras koodis toimub ja mida peab tegema. Sellega seoses lugesin meie andmeteaduse sõpradelt päris huvitava mõtteavalduse:

The Data is the Specification: A Manifesto for Iteratively Solving Complex Problems

Me oleme siin aines ka teste niimoodi üles ehitanud, et alustame lihtsalt sellega, et tagastame arvkonstandi Num(42) puhul tema väärtuse 42. Sellega võiks ju hakkama saada. Siis tegeleme muutujatega ja järjest keerulisemate avaldistega.

Kuidas istub selline lähenemine? (Siin on kõik vastused õiged... Vali see variant, mis kõige paremini sobib. Järgmisel küsimusel võid vabas vormis täpsustada.)

Kui jätame kõrvale see minu pealesurutud propaganda, siis kuidas suhtud ise koodi korrektsusesse? (Kõik vastused on siin õiged...)

Viimaste kodutöödega on üsna palju tehnilisi detaile, aga kas põhimõtted on selgeks saanud? Hinda ennast, kas järgmised teemad on kodutööga selge. Tehnilistel põhjustel pead kõike neid ära märkima, et täisarv punkte saada või ütleme, et küsimus on siin, kas hindasid ennast või ei viitsinud selle punkti üle mõelda.

Kontekstivaba grammatikaga tahame jällegi süvendada teie arusaamist programmide ülesehitustest, aga me anname ka vaba käsi oma grammatikad disainida ja see on hea koht jälgida hea disaini tavasid. Avaldisgrammatika lehel on üks suur pilt, kus on mainitud mõned hea süüsteemidisaini tavad, mida avaldusgrammatika jälgib. Mis need on? Selle küsimusega ma muidugi loodan, et teil tekib natuke huvi nende põhimõtetega lähemalt tutvuda.

Millise reegli võib lisada ilma et grammatika muutuks vasakrekursiivseks?

S → A

Kas antud grammatika on vasakrekursiivne?

S → A

Kas antud grammatika on vasakrekursiivne?

S → AB

Eemaldame järgmisest grammatikast vasakrekursiooni:

Ülalt-alla parseri järgmise sammu määrab hetkel vaadeldav …