1 Mitä funktionaalinen ohjelmointi on?

1 Mitä funktionaalinen ohjelmointi on? On olemassa useita erilaisia ohjelmointiparadigmoja (programming paradigms) koska on useita erilaisia tapoja mallintaa ohjelmointiongelmia, esimerkiksi: Proseduraalinen ohjelmointi jossa mallinnuksen voi ajatella keskittyvän ohjaamaan tietokonetta. Esimerkkikieli: C. Olio-ohjelmointi jossa mallinnus keskittyy löytämään ongelmassa esiintyviä olioita ja niiden välisiä suhteita. Esimerkkikieliä: Java, C++, Objective C,... Tietovuo-ohjelmointi jossa mallinnus keskittyy tiedon kulkuun eri komponenttien välillä. Esimerkki ohjelmointiympäristöstä: LabView. Logiikkaohjelmointi jossa ongelma mallinnetaan loogisina relaatioina ja ohjelman suoritus todistamisena. Esimerkkikieli: Prolog. Ohjelmointiparadigmat liittyvät mallinnukseen, joten ne ovat sinänsä ohjelmointikielistä riippumattomia, mutta jokaiselle paradigmalle on suunniteltu omia kieliään, joilla siten suunniteltuja ohjelmia olisi vaivatonta kirjoittaa. Tällä kurssilla esiteltävä paradigma on siis Funktionaalinen ohjelmointi jossa mallinnus keskittyy löytämään ongelmasta sellaisia tiedon muunnoksia jotka voidaan esittää matemaattisina funktioina annetuilta syötetiedoilta haluttihin tulostietoihin. Ohjelmoinnissa funktion matemaattisuus tarkoittaa sitä, että se ottaa sisään informaatiota vain parametreissaan antaa ulos informaatiota vain tuloksessaan, ja tämä tulos riippuu vain sisään tulleesta informaatiosta. Tilaperustainen ja tilaton ohjelmointi Mutta meillähän on jo tuttu aliohjelman käsite! Mitä uutta funktionaalinen ohjelmointi muka tuo? Aliohjelma ei välttämättä ole funktio, koska se ei välttämättä noudata tätä informaationkulkukuria, vaan se voi lukea muistista (tai käyttäjältä tai tiedostosta tai...) jonkin ohjelmallisen muuttujan nykyisen arvon ja tämä on lisäinformaatiota joka ei näy sen argumenteissa! kirjoittaa tällaiselle muuttujalle uuden arvon jonka jälkeen tämän (tai jonkin toisen!) aliohjelman seuraava kutsukerta voikin palauttaa jonkin toisen arvon, vaikka sen saamat argumentit pysyisivätkin samoina! Hyvä ohjelmointapa kehottaa välttämään tällaisia aliohjelmia, koska ne vaikeuttavat ohjelman debuggausta ja muokkaamista. 1

Funktionaalisessa ohjelmoinnissa pyritään välttämään sellaisia jo suunnitteluvaiheessa. Yleisemmin eri ohjelmointiparadigmat voidaan ryhmitellä tilaperustaisiin joissa ohjelma sisältää sijoituslauseita (assignment statement) joka tämä = tuo 1 ensin laskee tuon lausekkeen (expression) arvon ja 2 sitten tallentaa sen tämän muistipaikan uudeksi sisällöksi. Ohjelman suoritus etenee askelin yhdestä muistin tilasta (eli sisällöstä) seuraavaan. Proseduraalinen ohjelmointi on tilaperustaista puhtaimmillaan: ohjelmoija kirjoittaa haluamansa askelsarjat. Useimmat olio-ohjelmointitavat ovat tilaperustaisia, joskin epäsuoremmin: oliolla on sisäinen tila jota sen metodit muokkaavat. tilattomiin joissa ohjelmoija ei käytäkään tällaista muokattavaa muistia ja ohjelman suoritus ei etenekään tällaisesta tilasta seuraavaan vaan jotenkin muuten. Funktionaalinen ohjelmointi on tilatonta: Muuttujaa määriteltäessä sille annetaan jokin arvo jota ei muuteta enää myöhemmin. Siten määrittely tämä = tuo antaa tämän nimen tuon lausekkeen arvolle. Ohjelman suoritus etenee laskemalla lausekkeiden arvoja (eikä tottelemalla lausein ilmaistuja käskyjä). Funktionaalista ohjelmointia kutsutaankin myös soveltavaksi (applicative) koska sen suoritusaskel on muotoa sovella (apply) tätä funktiota tuohon argumenttiin. Viittausten läpikuultavuus Tämä arvon nimeäminen mahdollistaa sen, että voimme korvata kaikki tämän nimen esiintymät lähdekoodissa tuolla lausekkeella, joka määritteli sen arvon, eikä ohjelman laskema tulos siitä muutu. Jos pelkän nimeämisen sijaan käytämmekin (uudelleen)sijoituslausetta, niin tätä ei voi enää tehdä, koska tämä muistipaikka voi sisältää eri arvoja eri aikoina ja nämä arvot riippuvat ohjelman suoritushistoriasta, joka ei näy pelkästä lähdekoodista. Samoin jos tuo lauseke sisältää sivuvaikutuksia, kuten syötteen lukemista käyttäjältä. Viittausten läpikuultavuus (referential transparency) tarkoittaa sitä, että ohjelmointikieli sallii tämän korvaamisen, koska tuon lausekkeen arvo on aina sama (eikä se riipu esimerkiksi siitä milloin se lasketaan). 2

Viittausten läpikuultavuus pätee pätee funktionaalisesti tehdyn ohjelmakoodin kaikissa niissä osissa, joissa ei käytetä kielen tilaperustaisia piirteitä voi rikkoutua tilaperustaisen ohjelmakoodin missä tahansa osassa, koska missä tahansa voi taphtua esimerkiksi uudelleensijoitus. Jos ohjelmoija voi luottaa viittausten läpikuultavuuteen, niin hän voi käsitellä ohjelmakoodiaan matemaattisin menetelmin. Matemaattisten menetelmien soveltaminen tilaperustaiseen ohjelmointiin on epäsuorempaa: Voidaan käsitellä ohjelman loogista spesifikaatiota, eli loogisia väitteitä siitä mitä ohjelma tekee mutta ei itse ohjelmakoodia. Funktionaalinen ohjelmoija voi käsitellä koodiaan erityisesti algebrallisesti: Hän voi muodostaa koodiyhtälöitä koodi koodi (1) jotka tarkoittavat ohjelmakoodinpätkä koodi laskee kaikilla muuttujiensa arvoilla saman tuloksen kuin ohjelmakoodinpätkä koodi. Viittausten läpikuultavuuden nojalla hän voi korvata ohjelmakoodinpätkän toisella koodiyhtälönsä (1) mukaisesti, eikä ohjelman muu koodi mene siitä rikki. Tilallisessa ohjelmoinnissa koodiyhtälöitä (1) on hankalampi muodostaa ja tarkistaa: Päteekö esimerkiksi koodiyhtälö 1 y = 1 x; 2 if x y 3 P 4 else Q 1 y = 1 x; 2 P kaikilla kokonaisluvun sisältävillä muistipaikoilla x ja y? (P ja Q ovat mielivaltaista ohjelmakoodia.) Ei jos x ja y ovat sama muistipaikka! (Muuten kyllä.) Se voi puolestaan riippua (ei vain näistä ohjelmakoodinpätkistä vaan myös) ohjelman muusta tilasta ja suoritushistoriasta: Olkoot x ja y viittaukset a[i] ja a[j] samaan taulukkoon a. Tämän vuoksi tilallisessa ohjelmoinnissa tavallisesti todistetaankin konkreettinen koodi toimivaksi eikä yritetä lausua abstraktimpia yleisperiaatteita kaikilla x ja y pätee....... Tällaisessa todistuksessa käsitellään loogisia väitteitä jotka koskevat suorituksen tilaa ohjelmakoodin eri kohdissa väitteet ilmaistaan eri kielellä kuin koodi. 3

Miksi funktionaalinen ohjelmointi on kiinnostavaa? Ohjelmistotekniikan näkökulmasta: Ohjelmoijan kannattaa tuntea erilaisia ohjelmointiparadigmoja, jotta kohdatessaan erilaisia ohjelmointiongelmia hän osaa valita kuhunkin niistä sopivimman. Jos sinulla on vain vasara, niin kaikki näyttää naulalta. Funktionaalinen ohjelmointi painottaa erittäin tiukkoja rajapintoja. Millaista sellainen ohjelmointi on vapauteen tottuneelle ohjelmoijalle? Funktionaalinen ohjelmointi painottaa koodin uudelleenkäytettävyyttä erilaisten abstraktioiden kautta ja tarjoaa siihen välineitä. Funktionaalinen ohjelmointi kannustaa näin kokoamaan ohjelmat monesta pienestä (aiemmin ohjelmoidusta) funktiosta. Teorian näkökulmasta: LAP-kurssilla mainitut Turingin koneet ovat hyvä teoreettinen malli sille, miten mekaaninen tilaperustainen laskenta etenee ja mitä sillä voidaan laskea. Turingin koneiden teoria ei kuitenkaan tarjoa kovin luontevaa mallia sille, mikä ohjelma on itsenäisenä käsitteenä erillään sitä suorittavasta laitteesta. Funktionaalisen ohjelmoinnin taustalla oleva λ-laskenta voidaan nähdä tällaisena ohjelmien teoriana. Funktionaalinen ohjelmointi on λ-laskennan kautta ohjelmaparadigmoista lähimpänä formaalin logiikan todistusteoreettisia ideoita. Funktionaalinen ohjelmanpätkä ja sen oikeellisuustodistus voidaan ilmaista samalla kielellä. Ohjelmointikielten näkökulmasta: Tämä λ-laskenta on myös yleisen ohjelmointikielten teorian perusväline. Se soveltuu funktionaalisen ohjelmoinnin lisäksi muihinkin ohjelmointiparadigmoihin. Esimerkiksi tilaperustainen ohjelmointikieli voidaan mallintaa muokattavan muistin ja λ-laskennan yhdistelmänä. Siinä yhdistelmässä λ-laskenta tarjoaa aliohjelman ja muuttujannimen käsitteet, mutta ne nimeävätkin muistipaikkoja. Ohjelmointikielten uusia ideoita esitelläänkin koekäyttöön usein ensin johonkin funktionaaliseen kieleen, koska niissä matka teoriasta käytäntöön on lyhyt. Siksi ohjelmointikielistä kiinnostuneen kannattaa tuntea myös λ-laskentaa ja funktionaalista ohjelmointia, vaikka pääkiinnostus olisikin muissa ohjelmointiparadigmoissa. Millaiseen ohjelmointitehtävään funktionaalinen ohjelmointi soveltuu erityisen hyvin? Sellaiseen, jossa saatuun syötteeseen kohdistetaan jokin (monivaiheinen) muunnos, ja lopuksi ilmoitetaan muunnoksen tuottama tulos. 4

Sellaiseen, jossa tällä muunnettavalla informaatiolla on lista- tai puurakenne. Tällaista on esimerkiksi XML-dokumenttien käsittely. Tällaista on myös ohjelmointikielen kääntäminen: 1 Selausvaihe lukee lähdekooditiedoston ja muuntaa sen alkiojonoksi. 2 Jäsennysvaihe muuntaa alkiojonon sitä vastaavaksi jäsennyspuuksi kieliopin mukaisesti. 3 Seuraavat työvaiheet kuten tyypintarkistus jne. käyvät läpi jäsennyspuuta ja lisäävät siihen uutta informaatiota. 4 Lopuksi koodingenerointivaihe käy läpi lopullisen jäsennyspuun ja tulostaa sitä vastaavan konekoodin tulostiedostoon. Millaiseen ohjelmointitehtävään funktionaalinen ohjelmointi ei sovellu kovin hyvin? Sellaiseen, jossa halutaankin tuottaa jokin vaikutus (eikä tulosta). Esimerkiksi ikkunoiva käyttöliittymä. Sellaiseen, jossa keskeisessä osassa on jokin tila jota luetaan ja päivitetään eri tavoin monessa eri kohdassa ohjelmaa koska silloin tämä tila toimii informaationsiirtokanavana ohjelman osien välillä. Esimerkiksi jonkin tietokannan ympärille rakennettu ohjelma. Sellaiseen, jossa on seurattava tarkasti suoitusajan ja muistin kulutusta. Esimerkiksi laiteläheinen ohjelmointi. Tällaisissa ohjelmointitehtävissä funktionaalisen ohjelmoinnin haasteena onkin modulaarisuus: Suunnitella sellaiset rajapinnat, joilla ohjelma voidaan osittaa funktionaaliseen ja ei-funktionaaliseen osaan sekä niiden väliseen kommunikointiin. 2 Lambda-laskennan perusteista Esitellään seuraavaksi λ-laskennan pääperiaatteet. Valitsemme ohjelmoijan näkökulman aiheeseen: Meille λ-laskenta on abstrakti melli ohjelmointikielelle. Tämä abstraktius tarkoittaa, että esitämme ohjelmointikielen ja sen toiminnan puhtaasti mekaanisena systeeminä joka käsittelee symbolisia lausekkeita. Me emme siis vetoa mihinkään taustalla olevaan tietokoneeseen (tai sellaisen abstraktiin malliin malliin, kuten Turingin koneisiin) jossa olisi muistipaikkoja joita ohjelman suoritus muokkaisi edetessään, tai muuhun sellaiseen. 5

Termien syntaksi Otetaan käyttöön joukko X Muuttujasymboleita. Tyypittömän λ-laskennan Termien kontekstiton kielioppi: Termi Muuttuja (2) λmuuttuja.termi (3) (Termi 1 Termi 2 ) (4) Termistä voi jättää pois sisäkkäisiä sulkuja sopimalla että ja niin edelleen. (Termi 1 Termi 2 Termi 3 ) on sama kuin ((Termi 1 Termi 2 ) Termi 3 ) (5) Sulkuja voi jättää pois myös sopimalla, että λ-abstraktion (3) sisällä oleva Termi on mahdollisimman laaja eli että sen Muuttuja näkyy mahdollisimman laajasti. Termiin voi myös lisätä sulkuja (...) selkeyttämään sen rakennetta lukijalle. Termien merkitysoppi Ohjelmoijina ajattelemme Termiä lähdekoodin pätkänä: λ-abstraktio (3) määrittelee funktion, jonka ainoa formaali parametri on tämä Muuttuja ja tulos on tuon Termin arvo tälle Muuttujalle annetulla argumenttiarvolla. Muuttuja (2) viittaa tällaiselle formaalille parametrille annettuun argumenttiarvoon. Soveltaminen (4) kutsuu sitä funktiota jota Termi 1 esittää sillä argumenttiarvolla jota Termi 2 esittää. Muuttujan x esiintymä Termissä f on vapaa jos se ei ole minkään λ-abstraktion (3) λx.g sisällä, eli sen Termissä g sidottu muuten lähimpään sen sisältävään λ-abstraktioon (3) λx.g. Siten λ-abstraktioilla (3) on tuttu leksikaalinen näkyvyys (lexical scope). Termi on suljettu (closed) jos kaikki siinä olevat Muuttujan esiintymät ovat sidottuja. Määritellään λ-laskenta koodiyhtälöinä Termi Termi. Sellainen tarkoittaa intuitiivisesti, että kun valitaan mitkä tahansa Termit arvoiksi niissä vapaina esiintyville muuttujille, niin kummankin antama tulos on sama. Idea on sama kuin koodiyhtälössä (1). Emme kuitenkaan ole vielä määritelleet, mitä tarkoitamme tuloksella... 6

Määritellään keskeinen apuoperaatio f[x a] = Termi f jossa Muuttujan x jokainen vapaa esiintymä on korvattu Termillä a induktiolla yli Termin f rakenteen seuraavasti: { a kun y on sama Muuttuja kuin x y[x a] = y kun y on eri Muuttuja kuin x. Ylemmässä haarassa tapahtuu se korvaus. { λy.g kun y on sama Muuttuja kuin x λy.g[x a] = λy.(g[x a]) kun y on eri Muuttuja kuin x. Alemmassa haarassa vaaditaan myös, ettei Muuttuja y esiinny vapaana Termissä a, jotta tämä korvaus olisi laillinen. 2.1 α-konversio (g h)[x a] = ((g[x a]) (h[x a])). Ensimmäinen koodiyhtälömme on α-konversio (α-conversion): λx.f λy.(f[x y]) (α) jossa tämän korvauksen pitää olla laillinen. Laillisuus voidaan järjestää valitsemalla Muuttuja y sopivasti. Tämä α-konversio sanoo, että formaalille parametrille annetulla nimellä ei ole merkitystä. Ohjelmointikielen toteutuksessa ei tarvita tätä α-konversiota, koska käännetyssä koodissa ei enää ole Muuttujannimiä. Muistisääntö: α is about the alphabet. 2.2 β-reduktio Keskeisin koodiyhtälömme on β-reduktio (β-reduction): ((λx.f) g) f[x g] (β) jossa tämän korvauksen pitää olla laillinen. Vasemmalta oikealle luettuna se määrittelee mitä funktiokutsu tarkoittaa: Formaali parametri x korvataan argumentilla g kutsuttavan funktion rungossa f. Laillisuus voidaan aina järjestää tekemällä Termiin f ensin tarvittavat α- konversiot. Sellainen lauseke, joka on samaa muotoa kuin sen vasen puoli, on nimeltään redeksi (redex, reducible expression). Tämä β-reduktio on funktionaalisen ohjelman suorituksen perusaskel. Muistisääntö: β is the basic computation step. 7

Kuritus Vailla λ-laskennassa määritelläänkin vain 1-parametriset funktiot, niin siinä on myös 2-parametriset funktiot: ((λx.λy.f) g h) (((λx.(λy.f)) g) h) kun sulut merkitään näkyviin. Tämä selittää myös miksi näkymättömät sulut sovittiin näin päin. kun tehdään 1. β-reduktio. kun tehdään 2. β-reduktio. ((λy.(f[x g])) h) f[x g][y h] Siten 1. parametri x korvautui 1. argumentilla g, ja 2. parametri y korvautui 2. argumentilla h, kuten pitääkin. Näin k-parametrinen funktio voidaan kirjoittaa 1-parametrisena funktiona, jonka runko on (k 1)-parametrinen funktio, ja niin edelleen. Ääritapauksena vakiot ovat 0-parametrisia funktioita. Tämän tekniikan nimi on Currying. Suomeksi voisimme kutsua sitä kuritukseksi. Kuritus on yleistä funktionaalisessa ohjelmoinnissa, jossa on luontevaa määritellä sellainen funktio, joka palauttaa tuloksenaan toisen funktion. Funktionaaliset ohjelmointikielet mahdollistavat kurituksen, mutta useimmissa niistä sitä käytetään silti harvoin. Ohjelmointikielessä Haskell kuritusta käytetään hyvin usein. Kuritus lisää omalta osaltaan koodin modulaarisuutta, koska esimerkiksi osittain kutsuttu funktio ((λx.λy.f) g) voi olla hyödyllinen eri arvoilla h 1, h 2, h 3,... 2.3 η-konversio Kolmas koodiyhtälömme on η-konversio (η-conversion): f λx.(f x) jos Muuttuja x ei esiinny vapaana Termissä f. (η) Sen oikealla puolella voidaan ehkä tehdä sellaisia β-reduktioita, joita sen vasemmalla puolella ei voida tehdä (koska siellä ei ole Muuttujaa x). Näin se ilmaisee ekstensionaalisuus-idean: Kaksi Termiä tarkoittavat samaa täsmälleen silloin kun ne antavat saman tuloksen kaikilla argumenteilla. Toisin sanoen, vain Termin tuloksilla on väliä, mutta ei sillä miten se on kirjoitettu. Vastakkainen idea olisi nimeltään intensionaalisuus. Muistisääntö: η is about extensionality. 8

2.4 Normalisointi Normaalimuodon (Normal Form, NF) idea on yleisesti: Olkoon meillä jokin kieli, jossa voimme ilmaista saman asian monin eri tavoin. Keskitymme yhteen tiettyyn tapaan, ja muunnamme eli normalisoimme muut ilmaukset sellaisiksi. Esimerkiksi propositio- eli lauselogiikassa voimme käyttää negaatioita ( ), konjunktioita ( ) ja disjunktioita ( ) monin eri tavoin ilmaisemaan saman loogisen väitteen. Konjunktiivisessa normaalimuodossa (Conjunctive NF, CNF) keskitymme ilmaisemaan väitteet seuraavasti: Disjunktio Konjunktio Literaali Konjunktio Konjunktio Disjunktio Literaali Literaali Konjunktio Propositiosymboli Propositiosymboli Koska tahdomme määritellä käsitteen Termin tulos niin silloin luonteva normaalimuoto on: Termi on β-normaalimuodossa täsmälleen silloin kun siinä ei ole yhtään redeksiä. Intuitiivisesti, kun se on loppuun saakka laskettu. Usein etuliite β- jätetäänkin pois, ja niin mekin teemme. Normalisointi voidaan ilmaista yleisellä tasolla seuraavana pseudokoodina: normalisoi f 1 while Termissä f on yhä redeksejä 2 Valitse jokin niistä; 3 Korvaa se vastaavan β-reduktion oikealla puolella; 4 return f. Tämä on λ-ohjelmointikielemme toteutus epädeterministisenä (rivi 2) ja tulkattuna (rivi 3). Käytännössä ohjelmointikielet määritellään (useimmiten) deterministisinä ja ne voidaan toteuttaa kääntäjinä, joiden ei tarvitse etsiä ja korvata redeksejä. Termillä ei välttämättä ole normaalimuotoa. Esimerkiksi Termin normalisointi ei koskaan pääty. (λx.(x x)) (λx.(x x)) (6) Intuitiivisesti sellaiset Termit vastaavat päättymätöntä laskentaa. 9

normalisoinnin päättyminen voi riippua rivin 2 valinnoista. Esimerkiksi Termissä (λy.λz.z) (Termi (6)) (7) kutsuttava funktio ei käytä lainkaan parametriaan y, joten sen normalisointi pysähtyy, jos joskus valitaan se redeksi (eikä koko ajan Termiä (6)). Lause 1 (normaalimuodon yksikäsitteisyys). Jos Termillä on monia eri β-normaalimuotoja, niin ne saadaan täsmälleen samaan muotoon α-konversioilla. Siten voimme määritellä, että Termin tulos on sen (mikä tahansa) β-normaalimuoto, koska se on hyvin määritelty. Lause 1 osoittaa λ-laskennan kiinnostavuuden myös rinnakkaisuuden (parallelism) kannalta: Ohjelman lopputulos pysyy samana, vaikka sen eri osia β-redusoitaisiinkin yhtä aikaa. Kun λ-laskennalla mallinnetaan ohjelmointikieliä, niin silloin käytetäänkin jotakin heikkoa (Weak) normaalimuotoa β-normaalimuodon sijasta... jossa redeksin etsintä ei etene λ-abstraktion λx.g sisään sen alitermiin g... koska se on käännetty konekieliseksi aliohjelmaksi, ja sen alitermiin g muokkaaminen tarkoittaisi jo käännetyn konekoodin muokkaamista ja sellaista kutsutaan eikä muokata. Lause 2 (Turing-täydellisyys). Osittain määritelty funktio f : N N voidaan laskea Turingin koneella täsmälleen silloin kun f voidaan esittää tyypittömän λ-laskennan Terminä. Osittain määritelty (partially defined, partial) funktio g on sellainen, jonka tulosta ei olekaan määritelty jokaiselle mahdolliselle parametrin arvolle. Esimerkiksi g(n) = 1 n on sellainen, koska parametrin arvolla n = 0 sen tulosta 1 0 ei ole määritelty. Lauseen 2 vasenta puolta varten pitäisi ensin määritellä, mitä tarkoittaa että Turingin kone M laskee funktion f : Sovitaan luonnollisille luvuille N jokin esitystapa merkkijonoina, jotta Turingin koneet voivat lukea ja kirjoittaa niitä nauhoillaan. Kun moninauhainen M saa syötenauhallaan luvun n merkkijonona (ja sen mahdolliset työnauhat ovat aluksi tyhjiä) niin laskenta joko pysähtyy ja sen tulosnauhalla on arvo f(n) merkkjonona tai ei pysähdy jos arvoa f(n) ei ole määritelty. Kääntäen Lauseen 2 oikeaa puolta varten pitäisi määritellä, mitä tarkoittaa Termi h esittää funktion f : Sovitaan jokaiselle luonnolliselle luvulle n N jokin Termi n joka esittää sitä, jotta Termien voidaan ajatella laskevan luonnollisilla luvuilla. SovellusTermin normalisointi 10 (h n )

joko päättyy ja sen normaalimuoto on arvon f(n) esitys f(n) Terminä tai ei pääty kun arvoa f(n) ei ole määritelty. Lauseen 2 perusteella myös tyypittömien λ-termien normalisointi on eräs mekaanisen laskettavuuden (computability, eli sen mitä voidaan laskea) malli vaikka se ei olekaan lainkaan niin ilmeistä kuin Turingin koneilla. Toisin kuin Turingin koneilla, tässä mallissa on laiteriippumaton itsenäinen ohjelman käsite: Termit. Eräs yksinkertainen luonnollisten lukujen Termiesitys ovat Churchin numeraalit n = λf.λx.(f (f (f (...(f } {{ } n kappaletta eli sovella n kertaa funktiota f argumenttiin x. Siten 0 = λf.λx.x Esimerkiksi niiden yhteenlasku on 1 = λf.λx.(f x) 2 = λf.λx.(f (f x)). m + n = λf.λx.(( n f) ( m f x)). x)...)))) Lause 3 (normaali sievennysjärjestys). Jos rivillä 2 valitaan aina vasemmanpuoleisin redeksi, niin silloin Termin normalisointi päättyy jos sillä on jokin normaalimuoto. Näin käy esimerkiksi Termillä (7). Tämä valinta tarkoittaa, että kun redeksin etsintä aloitetaan koko Termin juuresta, ja kohdataan soveltaminen (Termi 1 Termi 2 ) niin siitä jatketaan etsintää ensin Termi 1 stä, ja jos sieltä ei löydy, niin vasta sen jälkeen Termi 2 sta. Tätä valintaperiaatetta kutsutaan normaaliksi sievennysjärjestykseksi (normal order reduction). Päänormaalimuodossa (Head NF) redeksiä etsitään soveltamisessa vain Termi 1 stä, ja Termi 2 unohdetaan. Lauseen 3 mukaan valitsemalla aina mekaanisesti Mene aina (ensin) vasemmalle! löydetään aina sellainen redeksi, jonka valitseminen on oikein, koska sen valitseminen ei voi johtaa normalisointia mihinkään ikuiseen silmukkaan, joka olisi voitu välttää valitsemalla jokin muu redeksi sen sijasta. Siten oikean redeksin valintaan ei (ehkä yllättäen) tarvitakaan älykkyyttä, joten myös tyypittömien λ-termien normalisointi on eräs mekaanisen laskennan (computation, eli sen, miten voidaan laskea) malli vaikka se ei olekaan lainkaan niin ilmeistä kuin Turingin koneilla. 11

Lauseen 3 mukaan normaali sievennysjärjestys sallii koodiyhtälöiden vapaan käytön: Jos Termissä f korvataan jokin sen alitermi g jollakin toisella Termillä h jolla f h, niin Termin f normalisointi ei voi sen seurauksena muuttua pysähtyvästä pysähtymättömäksi. Muut sievennysjärjestykset eivät pysty takaamaan tätä! Normaalissa sievennysjärjestyksessä redeksi (funktio argumentti) suoritetaan niin, että argumenttia ei lasketakaan ennen kuin se lähetetään kutsuttavaan funktioon sen parametrina. Sen sijaan argumentti lasketaankin vain jos kutsuttava funktio tarvitsee sen arvoa. Esimerkiksi Termissä (7) kutsuttava funktio ei tarvitse argumenttinsa arvoa ja sen laskeminen johtaisikin ikuiseen silmukkaan. Tätä parametrinvälitystapaa kutsutaan nimellä CBN: Call by... Name jos argumentti lasketaan aina uudelleen jokaisen kerran kun funktio tarvitsee sen arvoa, koska se sai parametrinaan arvon nimen eli määritelmän. Need jos argumentti lasketaankin vain silloin kun funktio tarvitsee sen arvoa ensimmäisen kerran, ja se muistetaan myöhäisempiä kertoja varten. Tämtä kutsutaan myös laiskaksi (lazy) suoritukseksi, koska argumentti lasketaan vain jos sen arvoa tarvitaan, ja silloinkin vain kerran. Kun käytössä on Call by Name, niin β-reduktiot etenevät (λx.(x x)) ((λy.a y) b) ((λy.a y) b) ((λy.a y) b) (a b) ((λy.a y) b) (a b) (a b) koska argumenttilausekkeen kumpikin kopio β-redusoidaan erikseen. Kun käytössä on Call by Need, niin ne etenevät kuin (x x) jossa x on ((λy.a y) b) koska siinä muistetaan, että Muuttujan x molemmat esiintymät jakavat yhteisen argumenttilausekkeen. Sitten (x x) jossa x on (a b) koska tämä yhteinen argumenttilauseke β-redusoidaan vain kerran, ja sen arvo näkyy samalla kumpaankin esiintymään. Se tarkoittaa samaa kuin (a b) (a b). Nykyisissä ohjelmointikielissä käytetään kuitenkin tavallisesti muuta kuin normaalia sievennysjärjestystä: tavallisesti redeksi (funktio argumentti) määritelläänkin sievennettäväksi niin, että 12

1 ensin lasketaan argumentti arvoonsa a, ja vasta 2 sitten kutsutaan funktiota siten, että sen parametriksi annetaan tämä laskettu arvo a. Se voidaan määritellä normalisoinnissa siten, että 1 ensin normalisoidaankin sen argumentti näillä samoilla säännöillä, ja vasta 2 sitten suoritetaan tämän redeksin β-reduktio. Tätä parametrinvälitystapaa kutsutaan nimellä Call by Value (CBV). Sitä kutsutaan myös ahkeraksi tai innokkaaksi (eager) koska siinä riennetään laskemaan a tietämättä onko se tarpeen. Sitä kutsutaan myös tiukaksi (strict) koska a lasketaan siksi että niin ohjelma käskee tekemään. Kääntäen, CBN on non-strict, suomeksi vaikkapa rento. Ahkeraan ohjelmointikieleen voidaan lisätä tuki laiskuudelle (joko uutena piirteenä tai erillisenä kirjastona). Esimerkiksi Lisp-murteessa Scheme (Dybvig, 1996, luku 5.7) lauseke (delay e) ei laskekaan argumenttilausekkeensa e arvoa heti, vaan luo siitä lupauksen (promise) p, jonka (force p) myöhemmin lunastaa, eli sieventää lausekkeen e arvoonsa a. Jos sama p lunastetaan uudelleen, niin lauseketta e ei sievennetä uudelleen, vaan käytetään jo saatua arvoa a. Ohjelmoijan vastuulle jää kertoa koodissaan, mitkä sen osat hän haluaa suoritettavan laiskasti eikä ahkerasti koordinaatio laiskan ja ahkeran koodinsa välillä. Jos e ei ole funktionaalista koodia, niin a riippuu siitä, milloin p lunastetaan ensimmäisen kerran! pysytellä funktionaalisena laiskan koodinsa sisällä mutta ohjelmointikielet eivät voi yleensä varmistaa, että hän tottelisi... Laiskassaa ohjelmointikielessä on puolestaan käänteinen ongelma: Miten ohjelmoija voi kertoa koodissaan, että sen jokin osa pitääkin suorittaa ahkerasti eikä laiskasti? Erityisesti: Miten laiskassa kielessä ilmaistaan, että tämä osa koodia pitää suorittaa loppuun ennen kuin tuon osan suoritus alkaa? Koska laiska suoritusjärjestys riippuu vain siitä, mitä informaatiota kutsuttava funktio käyttää argumentistaan, niin ohjelmoijan on luotava tällainen riippuvuus: tämän funktion pitää tuottaa jokin sellainen välitulos, jota tuo funktio tarvitsee päästäkseen käyntiin. Silloin laiskankin suorituksen on pakko edetä samassa järjestyksessä kuin ahkera etenisi. 13

Ohjelmointikielemme Haskell käyttää tätä lähestymistapaa esimerkiksi siinä osassa ohjelmaa, jolla on oikeus suorittaa I/O-operaatioita. Haskell voi varmistaa tämän oikeuden jo ohjelmakoodin käännösaikana kehittyneen tyyppijärjestelmänsä vuoksi. Kolmas yleinen parametrinvälitystapa on Call by Reference (CBR) jossa kutsuttava funktio saakin parametrinaan sen muistiosoitteen johon argumentti on talletettu. Silloin kutsuttava funktio voi vaihtaa koko argumenttinsa arvon toiseksi. Siten CBR rikkoo funktioiden informaationkulkukuria, jonka mukaan informaatiota saa tulla ulos vain tuloksessa. Oliokielissä käytetään usein CBR-johdannaista, jossa funktio ei voi vaihtaa koko argumenttiaan kokonaan toiseksi olioksi, mutta se voi muuttaa sen sisältöä. Tätä johdannaista on kutsuttu nimellä Call by Worth (CBW). CBW on myös laiskuuden toteutustekniikka: Silloin ohjelmointikielen toteutuksen ajonaikainen järjestelmä (run-time system) voi muuttaa argumenttina saadun lausekkeen arvokseen. Näin saadaan toteutettua lasketun argumenttiarvon muistaminen siten, että kun kutsuttu funktio viittaa argumenttiinsa joskus myöhemmin, niin se näkeekin sille nyt lasketun arvon. Muistintaminen (memoization) on yleisnimi tällaiselle ohjelmointitekniikalle, jossa funktion toimintaa tehostetaan sisäisesti muistamalla sen laskemia välituloksia, vaikka funktio näyttääkin ulospäin yhä matemaattiselta. 2.5 δ-määritelmät Nämä αβη-periaatteet antavat puhtaan λ-laskennan, jossa on vain Termien funktioita, mutta ei minkään muun tyyppisiä alkioita. Esimerkiksi luonnolliset luvut N lisättiin leikisti päättämällä, että tietty Termi n esittää luonnollista lukua n N. Matematiikassa yleisesti ja ohjelmoinnissa erityisesti on kuitenkin hyödyllistä ajatella, että jotkut perusasiat kuten Z = {..., 2, 1, 0, 1, 2,...} ja B = {False,True} ja niiden alkeisoperaatiot on jo annettu valmiina. (Vertaa konearitmetiikka.) Sitten voimme tarkastella miten λ-laskennalla voi määritellä niille mutkikkaampia funktioita. δ-reduktiot ovat tekninen väline tähän. Muistisääntö: δ is about definitions. Esimerkiksi kokonaisluvut Z voidaan lisätä aidosti λ-laskentaan seuraavasti: Myös jokainen kokonaisluku on Termi. 14

Tällaiset vakiotermit ovat valmiiksi normaalimuodossaan (joten niitä ei tietenkään enää tarvitse laskea eteenpäin). Myös alkeisoperaatioita saa käyttää Termien muodostamiseen. Esimerkiksi p + Z q, jossa + Z on alkeisoperaation kahden kokonaisluvun yhteenlasku nimi, on Termi kun myös sen argumentit p ja q ovat. Tällaisen alkeisoperaation merkitysoppi on annettu kokoelmana (joka saa olla ääretön) δ-reduktioita ja niin edelleen. 0 + Z 0 0 0 + Z 1 1 0 + Z 2 2 1 + Z 0 0 1 + Z 1 2 1 + Z 2 3 Tällainen vasen oikea luetaan jos redeksiä etsittäessä kohdataan vasen puoli, niin korvataan se oikealla puolella. Ennen tätä korvausta kumpikin Termi p ja q on ensin pitänyt normalisoida vastaaviksi vakioiksi. Siten alkeisoperaatiot voivat tarvita argumenttiensa arvoja ahkerasti myös laiskassa kielessa. Ehtolauseke on puolestaan totuusarvojen B keskeinen alkeisoperaatio: Sen δ-reduktiot ovat if True toka vika toka if False toka vika vika. Se siis tarvitsee ensimmäisen parametrinsa totuusarvoa, mutta ei tokan eikä vikan parametrinsa arvoa. Itse asiassa tokan ja vikan arvoa ei saa laskea, ennen kuin on selvinnyt, kumpaa niistä tarvitaan. Siten ahkerakin kieli tarvitsee myös tämän rennon piirteen. Tämä piirre lisätään ahkeraan kieleen kontrollirakenteina kuten if... then... else... joilla ohjelmoija ohjaa käsin sievennyksen etenemistä. Laiska kieli ei puolestaan tarvitse tätä jakoa kontrollirakenteisiin ja lausekkeisiin, koska siellä if voidaan tulkita tavalliseksi funktioksi. 2.5.1 Ohjelmoijan tekemät määritelmät Myös ohjelmoija voi kirjoittaa omia määritelmiään muodossa Muuttuja = Termi ja nekin tulkitaan kuten alkeisoperaatioiden δ-reduktiot: Jos redeksin etsintä kohtaa tämän Muuttujannimen, niin korvaa se tuolla Termillä. Funktionaalinen ohjelma onkin kokoelma tällaisia määritelmiä, ja sen suoritus on annetun Termin redusointia niitä käyttäen. Nämä määritelmät saavat olla rekursiivisia eli niiden oikean puolen Termi saavat käyttää niiden vasenten puolten Muuttujannimiä. 15

Rekursio onkin arkipäiväistä funktionaalisessa ohjelmoinnissa: Ohjelmoinnin perustyökalu on funktionkutsu, eikä ole eroa kutsutaanko siinä jotakin toista vaiko tätä samaa funktiota. Tämä johtuu siitä, että funktionaalisessa ohjelmoinnissa kaikki toisto pitää ilmaista rekursion avulla: Miten tavallinen silmukka kuten kertomafunktion arvon laskenta 1 m = 1; 2 while n > 1 3 m = m n; 4 n = n 1; 5 return m n! = 1 2 3... n voisi pysähtyä, jos silmukan runko ei saakaan muuttaa sen ehdossa mainittujen muuttujien arvoja? Tämän silmukan rekursiivisessa muotoilussa fact = λn. if (n > 1) (n fact (n 1)) 1 (8) jokainen rekursiokutsu saakin oman paikallisen kopionsa muuttujasta n, ja niillä saa siten olla eri arvot. Funktionaalisen ohjelmoijan näkökulmasta silmukka onkin yksinkertaista rekursiota, eikä kaksi erillistä käsitettä. Arvon 2! laskenta etenee ahkerasti seuraavalla tavalla, jossa alleviivaus osoittaa sen kohdan, jota käsitellään seuraavaksi, ja alaindeksi osoittaa, mitä sille tehdään: fact 2 δ (λn. if (n > 1) (n fact (n 1)) 1) 2 β if (2 > 1) (2 fact (2 1)) 1 δ if True (2 fact (2 1)) 1 δ 2 fact (2 1) δ 2 fact 1 δ 2 ((λn. if (n > 1) (n fact (n 1)) 1) 1) β 2 (if (1 > 1) (1 fact (1 1)) 1) δ 2 (if False (1 fact (1 1)) 1) δ 2 1 δ 2. 16