OHJELMOINTIKIELTEN PERIAATTEET ANTTI-JUHANI KAIJANAHO

Transkriptio

1 OHJELMOINTIKIELTEN PERIAATTEET ANTTI-JUHANI KAIJANAHO SYKSY 2002

2 Copyright c 2002 Antti-Juhani Kaijanaho Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being Esipuhe, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

3 Esipuhe Tämä moniste on kirjoitettu Jyväskylän yliopiston tietotekniikan laitoksen laudaturkurssin Ohjelmointikielten periaatteet (3 ov) tarpeisiin. Mikään ei toki estä sen käyttämistä muuallakin, mutta on hyvä huomata, ettei tämä moniste (ainakaan nykyisessä muodossaan) korvaa hyvää kirjaa. Paras kirja tämän monisteen aiheesta, johon olen törmännyt, on Michael Scottin Programming language pragmatics. Se käsittelee aihetta laajasti ja antaa samalla yleiskuvan myös ohjelmointikielten toteutustekniikoista. Ravi Sethin Programming languages: concepts and constructs, Robert Sebestan Concepts of Programming Languages ja Kenneth Loudenin Programming languages: principles and practice (ensimmäinen laitos) ovat kaikki mainioita kirjoja, mutta niissä kaikissa on ongelmia kattavuuden tai vaatimustason suhteen. Sebestan kirjassa on vieläpä havaittavissa pientä asennevikaa tiettyjen kielten kohdalla. Opettaja: Jos käytät tätä monistetta kurssillasi (tai jos suosittelet sitä oheislukemistona), kerrothan siitä minulle. Tutustuisin mielelläni myös tämän monisteen muutettuihin versioihin. Mikäli monisteen lisenssi (ks. liite A) aiheuttaa ongelmia, poikkeuksista voidaan keskustella. Jyväskylässä syyskuussa 2002 Antti-Juhani Kaijanaho iii

4 iv

5 Apologia 2002 Tämä versio luentomonisteesta on syntynyt tyhjästä kiireen ja muun sellaisen säestyksellä. Toivottavasti se ei kovasti tahtia haittaa, mutta kaikki kommentit, risut ja parannusehdotukset otetaan mielellään vastaan. Jakelen monistetta syksyn aikana luennoilla ja kurssin kotisivulla mit.jyu.fi/antkaij/opetus/okp2002/. Koska kirjoitan monistetta sitä mukaa kun sitä kurssilla tarvitaan, ovat kaikki sivunumeroinnit ja lukunumeroinnit todennäköisesti rikki kurssin päättyessä. Samasta syystä monisteesta puuttuu sisällysluettelo. Yrittäkää kestää. Kiitokset seuraaville henkilöille, jotka ovat lupautuneet toimimaan monisteen esilukijoina: Markus Inkeroinen, Jonne Itkonen ja Tommi Kärkkäinen. Luonnollisesti kaikki virheet, jotka monisteesta löytyvät, ovat vain minun syytäni. Jyväskylässä 9. syyskuuta 2002 Antti-Juhani Kaijanaho v

6 vi

7 Luku 1 Johdanto Ohjelmointi on ongelmien ratkaisemista. Asiaa voi katsoa kahdelta kannalta: voi keskittyä ymmärtämään ongelmaa tai ratkaisumalleja. Voidaan ajatella, että maailma jakautuu kahteen osaan, ongelma-avaruuteen ja ratkaisuavaruuteen. Ohjelmoijan tehtävänä on siirtää ongelma (joka elää ongelma-avaruudessa) ratkaisuavaruuteen, jolloin siitä tulee ratkaisu. Ohjelmointikieli on ohjelmoijan pääasiallisin työkalu, ja kielen toteutus (kääntäjä tai tulkki) auttaa ohjelmoijaa ratkaisun luomisessa: kielen ominaisuudet ratkaisevat, kuinka syvälle ratkaisuavaruuteen ohjelmoijan tulee ongelmaansa viedä ja mistä lähtien kielen toteutus tekee sen ohjelmoijan puolesta. Tässä luvussa puhutaan yleisiä asioita ohjelmointikielistä: käsiteanalyysiä harrastetaan, sitten tarkastellaan kielten historiaa ja kehitystä, sitten mietitään kielten jaotteluja, ja lopuksi puhutaan kielensuunnittelun periaatteista. 1.1 Mikä on ohjelmointikieli Tällä kurssilla tarkastellaan ohjelmointikieliä. Lienee tarpeen yrittää rajata, mitä tuo käsite tarkoittaa. Käytännössä tuo käsite on riittävän hyvin ymmärrettävissä, että kaikki sen tietävät. Vai tietävätkö? Olen monta kertaa itse törmännyt ihmisiin, jotka kiven kovaan puhuvat HTML:stä ohjelmointikielenä. Minä en pidä sitä ohjelmointikielenä (eikä moni muukaan), mutta miten sen voisi rajata jollakin yleisellä säännöllä käsitteen ohjelmointikieli ulkopuolelle? Ohjelmointikielen määritteleminen (tai edes tyhjentävä luonnehtiminen) on todella vaikeaa. Voisi yrittää vaikka näin: Ohjelmointikieli on väline, jolla ihminen kertoo tietokoneelle, mitä sen pitäisi tehdä. 1

8 2 LUKU 1. JOHDANTO Ihan hyvä tuo on ensimmäiseksi yritykseksi. Siinä on kuitenkin ongelma. Se ei rajaa joitakin tärkeitä ei-ohjelmointikieliä pois: WIMP-käyttöliittymä (windows, images, menus and pointers) on väline, jolla ihminen kertoo tietokoneelle, mitä sen pitäisi tehdä. Samoin HTML tulee tulkituksi ohjelmointikieleksi. Tuosta ensimmäisestä yrityksestä puuttuu jotain oleellista: ohjelmointikielen täytyy olla ilmaisuvoimainen. Tässä päädytään äkkiä hyvin syvällisiin kysymyksiin mekaanisen laskennan ja muun sellaisen olemuksesta. Tässä riittänee muistaa, mitä Automaatit ja kieliopit -kurssilla puhuttiin Turingin koneesta: se on idealisoitu tietokone, yksinkertainen kone, joka kykenee ratkaisemaan kaikki mekaanisesti ratkaistavissa olevat ongelmat. Ehkäpä Turingin koneesta löytyisi sopiva mitta ohjelmointikielen ilmaisuvoimalle. Voidaan esittää vaikkapa seuraavanlainen uusi yritelmä määritelmäksi: Ohjelmointikieli on väline, jolla ihminen kertoo tietokoneelle, mitä sen pitäisi tehdä ja jolla voidaan saada tuo kone simuloimaan universaalia Turingin konetta. Tässä määritelmässä on myös ongelmansa. Todelliset tietokoneet toimivat todellisessa maailmassa, jossa on ainainen resurssipula: olipa esimerkiksi muistia kuinka paljon tahansa, aina sillä on jokin raja. Turingin koneella puolestaan on ääretön nauha. Ehkäpä tätä voisi korjata raja-arvotarkastelulla: Tarkastellaan välinettä, jolla ihminen kertoo tietokoneelle, mitä sen pitäisi tehdä. Tämä väline on ohjelmointikieli, mikäli periaatteessa niiden ongelmien joukko, jotka on kuvattavissa tuolla välineellä niin, että tuon kuvauksen perusteella kyseinen tietokone kykenee ratkaisemaan ne, lähestyy rajatta Turingin koneella ratkaistavien ongelmien joukkoa, kun koneen resurssirajat kasvavat rajatta. Tämä saattaa olla oikein tai voi olla olematta. Tämä määritelmä on hankala, käyttää vaikeita käsitteitä eikä käytä niitä edes mitenkään oikealla tavalla. Tehtävä 1 Onko olemassa hyvää ohjelmointikielen määritelmää? Muutama erottelu on kuitenkin tehtävä selväksi. Tällä kurssilla ei puhuta dokumentinkuvauskielistä (kuten HTML) paitsi jos ne ovat toisaalta myös ohjelmointikieliä (heh! viittaan tässä TEXiin ja Postscriptiin). Myös spesifiointikielet (kuten Z ja B) jätetään kurssin ulkopuolelle (Formaalien menetelmien kurssilla puhutaan niistä) ohjelmointikielen määritelmään täytyy jotenkin lisätä se, että kielellä kirjoitetut ohjelmat pitää olla käännettävissä algoritmisesti konekielelle.

9 1.2. HISTORIA Historia Kaksi ensimmäistä sukupolvea: ennen vuotta 1955 Ensimmäiset ohjelmointikielet olivat konekieliä ja niillä kirjoitetut ohjelmat olivat bittijonoja tietokoneen muistissa. Ohjelmat syötettiin koneelle kytkimiä kääntelemällä. Konekieli on ratkaisuavaruuden sydämessä: konekielellä ei ole kääntäjää tai tulkkia, joka auttaisi ihmistä ongelman tuomisessa ratkaisuavaruuteen. Esimerkki 1 Seuraavassa on Hello World -ohjelma erään tietokoneen konekiellä (esitettynä 16-lukujärjestelmässä tavujonona) d6e f686a656c6d612e6d6d f4ff c6c f2c f726c a a00ff b a d e c c0008 Kyseinen kone on Donald E. Knuthin legendaarisen kirjasarjansa The Art of Computer Programming uusia laitoksia varten suunnittelema RISC-prosessori MMIX Ohjelmien kirjoittaminen konekielellä on erittäin virhealtista ja toisaalta hyvin mekaanista puuhaa. Jo hyvin varhaisessa vaiheessa alettiin kirjoittaa ohjelmia, jotka auttoivat tässä prosessissa. Ihmiset kirjoittivat sopivalla tavalla muotoiltua tekstiä, ja nämä ohjelmat muunsivat sen konekieleksi. Tyypillisesti tässä syötteessä yksi rivi vastaa yhtä konekielen käskyä. Tätä ohjelmointikieltä kutsutaan symboliseksi konekieleksi (engl. assembler language), ja ohjelmaa, joka kääntää tällä kirjoitetun ohjelman konekielellä, sanotaan assembleriksi. Esimerkki 2 Edellisen esimerkin ohjelma MMIX:n symbolisella konekielellä (MMIXAL) kirjoitettuna näyttää tältä: LOC #100 Main GETA $255,Str TRAP 0,Fputs,StdOut TRAP 0,Halt,0 Str BYTE "Hello, World!" BYTE #0a 1. Donald E. Knuth. MMIXware: A RISC Computer for the Third Millennium. Lecture Notes in Computer Science Berliini, Springer Katso myös sivua stanford.edu/ knuth/mmixware.html

10 4 LUKU 1. JOHDANTO Konekielet muodostavat ohjelmointikielten ensimmäisen sukupolven ja symboliset konekielet ohjelmointikielten toisen sukupolven. Ongelmana näissä on ohjelmoinnin virhealttius ja vahva mekaanisuus sekä se, että jokaisella konetyypillä on oma konekielensä ja sitä vastaava symbolinen konekieli. Ohjelmia ei voitu siirtää konetyyppien välillä, vaan ne jouduttiin kirjoittamaan uudestaan aina kullekin uudelle konetyypille Automaattinen ohjelmointi ja ohjelmointikielten synty: Ongelman ratkaisuksi esitettiin automaattista ohjelmointia, joksi sitä silloin 1950-luvun alkupuolella sanottiin. Kyse oli siitä, että ohjelmoija esittää tietokoneelle ongelman kuvauksen jollakin formaalilla kielellä, ja jokin erityinen ohjelma tuottaa siitä konekielisen ohjelman, joka ratkaisee ongelman. Eivät ne formaalit kielet mitenkään kummoisia olleet, mutta senaikaiseen tietämykseen nähden ne olivat tekoälytutkimuksen (josta ei tuota nimeä vielä käytetty) huippua. Nykyään näitä formaaleja kieliä sanotaan korkean tason tai kolmannen sukupolven ohjelmointikieliksi ja ohjelmia, jotka tekevät niillä kirjoitetuista ongelmakuvauksista konekielisiä ohjelmia, sanotaan kääntäjiksi (compiler). Näitä varhaisia kieliä on esitelty Knuthin ja Trabb Pardon artikkelissa vuodelta Automaattiseen ohjelmointiin eivät useimmat ihmiset uskoneet, ennen kuin Fortran tuli kuvioihin 1950-luvun lopulla ensimmäinen versio julkaistiin keväällä 1957, mutta kielestä oli siinä vaiheessa puhuttu jo monta vuotta. Fortran oli ensimmäinen merkittävää kannatusta saavuttanut korkean tason ohjelmointikieli (ja kiinnostavaa kyllä, edelleen laajassa käytössä, tosin reilusti muuttuneena). Ensimmäinen Fortran-kääntäjä oli vaikea tehtävä: sitä tehtiin kolme vuotta ja siihen kului 18 ihmistyövuotta. Tätä työtä johti John Backus, joka on myöhemminkin ollut merkittävä tekijä ohjelmointikieliteknologian alalla. Fortanin merkitys ohjelmointikielten kehitykselle on kiistaton. Se oli alan pioneerityö: se sai ihmiset uskomaan korkean tason ohjelmointikieliin ylipäätään. Lisäksi monet sen ominaisuudet ovat edelleen ohjelmointikielissä tärkeitä: taulukkomuuttujat, muuttujan ohjaamat silmukat (ns. for-silmukat) sekä haarautuva if-lause (if statement) ovat nykykielissäkin peruskamaa. 2. Donald E. Knuth ja Luis Trabb Pardo. The Early Development of Programming Languages. Julkaistu alunperin J. Belzerin, A. G. Holzmanin ja A. Kentin toimittamassa kirjassa Encyclopedia of Computer Science and Technology, vol. 6, New York, Dekker, Julkaistu uudelleen mm. N. Metropolisin, J. Howlettin ja Gian-Carlo Rotan toimittamassa kirjassa A History of Computing in the Twentieth Century, New York, Academic Press, 1980.

11 1.2. HISTORIA 5 Fortran oli tarkoitettu tieteellisen laskennan ohjelmien kirjoittamiseen. John McCarthy, tekoälytutkimuksen kantaisä, halusi kielen symbolista tiedonkäsittelyä (esimerkiksi algebrallisten funktioiden symbolista derivointia) varten. McCarthy ja muutamat muut laajensivat Fortrania aluksi symbolista laskentaa varten, mutta tämän rajat tulivat pian vastaan. He aloittivat uuden kielen, Lispin, kehittämisen ensin paperilla ja käsikääntäen sillä kirjoitettuja ohjelmia paperille. Kun sitten huomattiin, että teoreettiseksi leluksi tarkoitettu Lisp-funktio eval toimii mainiosti Lisp-tulkkina, oli Lisp-toteutus valmis 3. Fortranin tapaan Lispin merkitys myöhemmille ohjelmointikielille on merkittävä. Lispin mukana näkivät päivänvalon mm. rekursiiviset aliohjelmat, muistinsiivous (garbage collection) ja if-lauseke (if expression). Nykyisin Lispistä on käytössä kolme merkittävää murretta: Emacs Lisp, Common Lisp ja Scheme. Algoritmien julkaisemiseen kehitettiin komiteatyönä 1950-luvun lopulla uusi kieli, Algol (tämän sanotaan usein olevan lyhenne sanoista Algorithmic language, mutta se viittaa myös samannimiseen kolmoistähteen). Algol 60 4 oli kolmas 1950-luvun loppupuolella kehitetty kieli, jolla on ollut merkittävää merkitystä ohjelmointikielten tulevalle kehitykselle. Algol 60 oli ensimmäinen lohkorakenteinen kieli. Sillä oli vapaamuotoinen, rakenteinen syntaksi. Siinä oli muuttujien tyyppien esittelyt ja arvovälitteiset (call-by-value) aliohjelmaparametrit. Nämäkin kaikki ovat lähes välttämättömiä nykykielissä. Tony Hoare kirjoitti Algol 60:stä vuonna 1973 seuraavasti: Tässä on kieli, joka on niin edellä aikaansa, että se oli paitsi edeltäjiään myös lähes kaikkia seuraajiaan parempi luvun lopulla kehitettiin myös kaksi muuta suosiota saavuttanutta kieltä, Cobol ja APL. Kummankin merkitys ohjelmointikielten kehitykselle kokonaisuutena on kuitenkin vähäinen, joten niihin ei tämän enempää puututa Baabelin torni: 1960-luku 1960-luvulla suunniteltiin satoja uusia ohjelmointikieliä, joista hyvin harva jäi eloon. Nimet Adam, AED, Altran, CLP, Dyana ja Unicode eivät nykyään liity ohjelmointikieliin lainkaan mutta ne kaikki olivat vuonna 1967 käytössä 3. John McCarthy. History of LISP. ACM SIGPLAN Notices, vol. 13, no. 8, August 1978 (preprints, ACM SIGPLAN History of Programming Languages Conference). 4. Peter Naur (toim.), J. W. Backus ym. Revised Report on the Algorithmic Language AL- GOL 60. Communications of the ACM, vol. 6 no. 1, January C. A. R. Hoare. Hints on programming-language design. Julkaistu mm. C. A. R. Hoaren ja C. B. Jonesin kirjassa Essays in Computer Science, New York, Prentice Hall, 1989.

12 6 LUKU 1. JOHDANTO olleita ohjelmointikieliä. Monet näistä kielistä olivat tarkoitettu johonkin erityiseen tarkoitukseen. Algol-perhe sai uuden jäsenen, Algol 68:n, joka kokonsa ja vaikealukuisen määrittelynsä 6 vuoksi sai huonon maineen ja jäi pääosin käyttämättä. Samoihin aikoihin Niklaus Wirth ja Tony Hoare suunnittelivat oman seuraajansa Algol 60:lle, jota on kutsuttu Algol W:ksi. Norjalaiset Kristen Nygaard ja Ole-Johan Dahl kehittivät Simula-kielen simulointien kirjoittamiseen. Simulan merkitys nykykielille on ollut valtava, samaa suuruusluokkaa kuin Algol-perheen ja Lispin: Simulasta alkoi olio-ohjelmoinnin perinne jo Simula I:n yhteydessä puhuttiin olioista ja luokista. Perintä lisättiin Simula 67:ään. David Farber, Ralph Griswold ja Ivan Polonsky kehittivät Snobol-kielen merkkijonojen käsittelyä varten Snobol vaikutti suuresti tulevien kielten (esimerkiksi Perlin) merkkijono-ominaisuuksiin luvun lapsia on myös BASIC. Dartmouth Collegessa haluttiin luoda tietokonejärjestelmä ja sille ohjelmointikieli, jotka ovat niin helppoja, että niiden käyttöä voitaisiin opettaa kaikille humanisteille. BASIC sai monia vaikutteita Algol 60:stä, mutta jätti monta (näin jälkiviisaasti sanoen: hyvin tärkeätä) sen ominaisuutta pois. Esimerkiksi lohkorakenne tiputettiin pois, koska sitä ei haluttu selittää humanisteille 7. IBM:n ja muun teollisuuden yhteistyönä kehitettiin 60-luvulla PL/I (oikeastaan PL/1, mutta ykkönen on tapana tässä tapauksessa kirjoittaa isona I-kirjaimena), joka oli yritys luoda eräänlainen universaali ohjelmointikieli. Aiemmin oli ohjelmointitehtävät ja ohjelmoijat jakautuneet kahteen selvään ryhmään: tieteellinen laskenta, jossa tarvittiin liukulukulaskentaa, taulukoita ja aliohjelmia, sekä hallinnollinen tietojenkäsittely, jossa tarvittiin kiintolukulaskentaa (fixed-point arithmetic), tehokasta siirräntää (input/output) ja merkkijonojen käsittelyä luvulla tämä jako alkoi hämärtyä, ja eräs PL/I:n oleellisimmista tavoitteista oli toimia molempien ryhmien ohjelmointikielenä. Kieli oli 60- ja 70-luvuilla varsin suosittu ja IBM tukee sitä edelleen, mutta nykyisin sitä pidetään (yhdessä Algol 68:n kanssa) lähinnä varoittavana esimerkkinä laajasta ja vaikeasta kielestä. PL/I oli ensimmäinen ohjelmointikieli, joilla on muodollisesti (PL/I:n tapauksessa VDM:llä) määritelty merkitysoppi (semantics). 6. A. van Wijngaarden ym. (toimm.). Revised Report on the Algorithmic Language Algol 68, Berliini, Springer, Thomas E. Kurtz. BASIC. ACM SIGPLAN Notices, vol. 13, no. 8, August 1978 (preprints, ACM SIGPLAN History of Programming Languages Conference).

13 1.2. HISTORIA Modernismin alku: 1970-luku 1970-luvulla alettiin rakentaa edellisen vuosikymmenen Baabelin tornin raunioiden päälle. Tärkeinä lähtökohtina pidettiin kielen yksinkertaisuutta ja johdonmukaisuutta. Samaan aikaan puhuttiin paljon rakenteisesta ohjelmoinnista 8 (structured programming), ja monet 70-luvulla suunnitelluista kielistä oli nimenomaisesti suunniteltu rakenteista ohjelmointia ajatellen luvun kielet ovat ensimmäisiä, joita voi kutsua moderneiksi. Edellisinä kahtena vuosikymmenenä oli kehitetty niin paljon kieliä, että niiden virheistä saattoi oppia jotain merkittävää luvun jälkeen on myöskin ilmaantunut hyvin vähän radikaaleja, uusia ideoita ohjelmointikielten alalla kielet ovat kyllä kehittyneet mutta vähittäin. Niklaus Wirth ei todellakaan pitänyt Algol 68:sta. Hän alkoi suunnitella uutta kieltä Algol-perinteen sisällä aiemman Algol W:nsä pohjalta. Tulos oli Pascal, toisaalta opetukseen mutta toisaalta myös käytännön ohjelmointityöhön tarkoitettu kieli. Pascalin eräs varhainen, aikoinaan suosittu toteutus perustui samantyyppiselle virtuaalikoneratkaisulle kuin Java nykyisin. Toinen Algol-perinteeseen kytkeytynyt uusi kieli oli Dennis Ritchien C. C oli tarkoitettu raakaan järjestelmäohjelmointiin: sillä oli tarkoitus kirjoittaa (ja kirjoitettiinkin) UNIX kokonaan uudestaan. C:n merkitystä myöhemmille kielille on vaikea yliarvioida, vaikka se sinänsä ei sisältänytkään juuri mitään kieliteknologista uutta sen merkittävyys johtuu siitä, että se on erittäin suosittu. Olio-ohjelmointi ei vielä 1970-luvulla ollut kovin merkittävässä asemassa. Xeroxin PARC-laboratorioissa kehitettiin WIMP-käyttöliittymää, ja merkittävä osa tätä kehitystyötä oli Smalltalk-kielen kehitys. Smalltalk on edelleen yksi puhtaimmista oliokielistä. Itse kieli on hyvin pieni, mutta sen peruskirjasto on järkyttävän suuri. Funktio-ohjelmointi oli 1970-luvulla rajoittunut lähinnä Lisp-sukuisten kielten käyttöön. Robin Milner kehitti Edinburghin yliopiston päättelyavustimen käyttöön metakielen (kielen, jolla kuvataan kieliä), jota hän kutsui ML:ksi (lyhenne sanasta meta-language). Sen tapa ajatella ohjelmia sai paljon vaikutteita Lispistä mutta sen syntaksi on Algol-tyyppinen. ML:n ehkä suurin merkitys ohjelmointikielten kehitykselle on Hindley Milner-tyyppijärjestelmä 9, jota mm. Generic Java käyttää tietyin muunnoksin. 8. O.-J. Dahl, E. W. Dijkstra ja C. A. R. Hoare. Structured Programming, Lontoo, Academic Press, Robin Milner: A Theory of Type Polymorphism in Programming. Journal of Computer and System Sciences, vol. 17, no. 3, December 1978.

14 8 LUKU 1. JOHDANTO Samoihin aikoihin Guy Lewis Steele, Jr. ja Gerald Jay Sussman kehittivät uutta Lisp-varianttia, jonka he nimesivät Schemeksi. Scheme käytti Lispin omintakeista Cambridgen-puolalaista 10 syntaksia mutta otti käyttöön Algoleista tutun lohkorakenteisuuden. Schemen kehittäjät olivat vahvasti sitä mieltä, että aliohjelmakutsun ei todellakaan tarvitse olla hidas operaatio 11, ja he suunnittelivat kielensä (ja sen toteutukset) tuon käsityksen ympärille. Schemen määrittelyyn kuuluu edelleen vaatimus häntäkutsun poistamisesta (tähän palattaneen tuonnempana), mitä juuri mikään muu kieli ei nykyisin vaadi, vaikka syytä olisi luvun alussa syntyi ohjelmointikieli nimeltään Prolog, joka oli täysin erilainen kuin aiemmat kielet, eikä nykyisistäkään kielistä kovin monta samantyyppistä löydy. Prologin perusidea on predikaattilogiikan kaavojen tulkitseminen proseduraalisesti siten, että ohjelma koostuu kaavoista, jotka tulkitaan aliohjelmiksi, ja jonkin näistä aliohjelmista kutsuminen vastaa sitä vastaavan kaavan todistamista muiden toimiessa aksioomina Olio-ohjelmoinnin ja juontokielten nousu: 1980-luku 1980-lukua voi hyvällä syyllä sanoa olio-ohjelmoinnin popularisoinnin vuosikymmeneksi. Tällä vuosikymmenellä kehitettiin monta merkittävää olio-ohjelmointiin käytettyä kieltä. Samalla myös funktio-ohjelmoinnin tutkimus eteni, ja vaikka funktio-ohjelmointi ei saavuttanutkaan samaa suosiota kuin olioohjelmointi, myös sen kannalta merkittäviä kieliä kehitettiin luvun alussa alkoi Bjarne Stroustrup kehitellä oliolaajennusta Ritchien C- kieleen. Hän kutsui tuota kieltä nimellä C with classes, mutta varsin pian nimi vaihtui C++:ksi. Vaikka C++ alkoikin oliokielenä, on siihen myöhemmin lisätty paljon muitakin ohjelmointityylejä tukevia ominaisuuksia esimerkiksi C++:n tyyppijärjestelmästä kehittyi oma funktiopohjainen ohjelmointikielensä C++:n sisälle! Toinen tunnettu 1980-luvulla kehitetty oliokieli on Bertrand Meyerin Eiffel. Se on puhdas oliokieli ja sisältää myös tukea ohjelmien formaalille verifioinnille (esi- ja jälkiehdot sekä luokkainvariantit on mahdollista esitellä ja tarkastaa ajoaikana samoja ominaisuuksia löytyi muutamasta aiemmasta kielestä kuten Alphard ja Euclid). 10. John McCarthy. History of LISP. emt. 11. Guy Lewis Steele, Jr. Debunking the Expensive Procedure Call Myth or, Procedure Call Implementations Considered Harmful or, LAMBDA: The Ultimate GOTO. Julkaistu James K. Kethchelin ym. toimittamassa konferenssijulkaisussa Proceedings of the 1977 annual conference, ACM, 1977.

15 1.2. HISTORIA luvulla saatiin valmiiksi Yhdysvaltain puolustusministeriön toimeksiannosta kehitetty kieli Ada (Augusta Ada Byronin, Lovelacen kreivittären mukaan, jonka on sanottu olleen maailman ensimmäinen ohjelmoija). Adan tärkeimpiä sovelluskohteita olivat alunperin sulautetut järjestelmät ja tosiaikaohjelmistot, erityisesti asejärjestelmät. David Turner kehitti funktiokielen Miranda 1980-luvun puolessa välissä. Se muistutti monessa suhteessa ML:ää, mutta se käytti johdonmukaisesti laiskaa laskentaa (tähän palataan vielä) ja oli puhdas funktiokieli. Mirandan käyttöä rajoitti Turnerin tapa pitää kielestään voimakkaasti kiinni: hän jopa patentoi osia siitä. Samantyyppisiä omia kieliä oli lähes jokaisella funktio-ohjelmoinnista kiinnostuneella tutkijalla, joten vähän myöhemmin perustettiin komitea suunnittelemaan uutta Mirandan kaltaista ohjelmointikieltä luvun loppupuolella syntyi kaksi merkittävää juontokieltä (scripting languages): John Ousterhoutin Tcl ja Larry Wallin Perl. Tcl:n pääideana oli olla kieli, jonka voisi upottaa ohjelmistoihin, Perl syntyi tarpeesta käsitellä tekstitiedostoja mitä erilaisimmin tavoin Internetin nousu: 1990-luku Vuonna 1993 alkoi Internetin ikuinen syyskuu, kun Internet alkoi vähitellen nousta tavallisten ihmisten tietoisuuteen. Samalla ohjelmoinnin fokus siirtyi kohti verkkosovelluksia. James Gosling työryhmineen kehitti Java-kielen, vuonna 1995 julkaistun C- sukuisen oliokielen, joka on niin konservatiivisesti suunniteltu, ettei siinä ole juuri mitään uutta. Javan, kuten muidenkin C-sukuisten kielten, merkitys on sen suosikkiasemassa. Aivan 1990-luvun alussa sai edellisellä vuosikymmenellä muodostettu funktiokielikomitea työnsä päätökseen. Tulos oli Haskell, jonka tarkoitus on olla se oikea laiskasti laskeva, puhdas funktiokieli. Tämä tavoite onkin onnistunut. Vuonna 1999 valmistui kielen nykyinen määrittely, Haskell 98. Haskell näyttäisi ratkaisseen funktiokieliä vaivanneen ongelman siirrännästä varsin omintakeisella monadisen tietotyypin käsitteellään. Jo 1980-luvulla alkanut juontokielten kehitys jatkui 1990-luvulla. Guido van Rossum kehitti Pythonin vuosikymmenen alussa, Yukihiro Matsumoto kehitti Rubyn. 90-luvun lapsia ovat myös PHP ja ECMAScript (tunnetaan myös nimellä Javascript).

16 10 LUKU 1. JOHDANTO Sukupolvista Olen edellä viitannut ohjelmointikielten ensimmäiseen, toiseen ja kolmanteen sukupolveen. Kukaan ei näytä tietävän, mistä koko sukupolvijaottelu on peräisin, ja lähteet määrittelevät sukupolvet kukin omalla tavallaan. Edellä esittelemäni määritelmät kolmelle ensimmäiselle sukupolvelle ovat jonkinlainen lähteiden konsensus, vaikka poikkeaviakin esityksiä olen nähnyt. Useimmat lähteet puhuvat myös neljännestä ja viidennestä sukupolvesta, mutta mitään yksimielisyyttä niiden sisällöstä ei ole. 1.3 Kielten jaotteluja Itse käytän seuraavanlaista karkeaa jaottelua: Käskykielten (imperative languages) juuret ovat syvällä ratkaisuavaruudessa, von Neumannin arkkitehtuurin perusrakenteissa. Käskykielet näkevät maailman joukkona muistipaikkoja, joita muutellaan yksitellen von Neumannin pullonkaulaa pitkin. Käskykielille tyypillistä on tuhoava sijoitus -operaatio sekä eksplisiittinen, peräkkäistykseen ja silmukkaan perustuva toiminnanohjaus (flow of control). Käskykieliä on kahta päätyyppiä, jotka eroavat toisistaan lähinnä pääasiallisen abstraktiokeinon osalta: Toimintokielet (procedural languages) abstrahoivat toimintaa aliohjelmiksi. Tunnettuja toimintokieliä ovat C, Pascal ja Fortran. Oliokielet (object-oriented languages) abstrahoivat dataa oliohierarkioiksi. Tunnettuja oliokieliä ovat Smalltalk, Eiffel ja Java. Myös mm. C++, Perl ja Python luetaan usein oliokielten joukkoon, vaikkeivät ne sitä varsinaisesti ole. Esittelykielten (declarative languages) juuret ovat ongelma-avaruudessa, ongelmien täsmällisessä kuvaamisessa yleensä matematiikan keinoin. Esittelykielten taustalla on vahva matemaattinen teoria, jota on sen verran rikottu, että näiden kielten toteutukset kykenevät itsenäisesti tekemään kielellä kirjoitetusta ongelman kuvauksesta enemmän tai vähemmän tehokasta konekieltä. Esittelykieliä on kahta päätyyppiä, jotka eroavat toisistaan lähinnä taustalla olevan matemaattisen teorian osalta: Funktiokielet (functional languages) perustuvat Churchin ja Kleenen 1930-luvulla kehittämään -laskentaan. Funktiokielten yksi pääviehätyksistä on viittausten läpinäkyvyys (referential transparency): jos lausekkeet ovat kerran yhtäsuuria, ne ovat aina yhtäsuuria.

17 1.3. KIELTEN JAOTTELUJA 11 Puhtaita funktiokieliä on vähän: nykykielistä vain Haskell on puhdas funktiokieli. Funktiokielten joukkoon lasketaan usein myös Lisp-perheen kielet (Scheme ja Common Lisp) sekä ML-perheen kielet (Standard ML ja OCaml), vaikka nämä ovatkin ominaisuuksiltaan lähempänä käskykieliä niillä on kuitenkin mahdollista ohjelmoida kuten funktiokielellä, ja tämä onkin niiden suosituin käyttötapa. Logiikkakielet (logic languages) perustuvat predikaattilogiikan osaan nimeltä Hornin logiikka. Prolog on ainoa tunnettu logiikkakieli, mutta myös muita on. Monet kielet eivät kuitenkaan tipu siististi mihinkään näistä lokeroista. Hyvä esimerkki on C++, jossa on toimintokielen, oliokielen ja funktiokielen vikaa sama pätee myös esimerkiksi Perliin ja Pythoniin. Tällaisia kieliä sanotaan toisinaan moniparadigmakieliksi (multiparadigm languages). Toisaalta on kieliä, jotka sijaitsevat koko jaottelun ulkopuolella. Hyvä esimerkki tällaisista kielistä on Prograph, jonka sanotaan kuuluvan visuaalisten ohjelmointikielten luokkaan. John Ousterhout 12 määrittelee järjestelmäohjelmointikielen ja juontokielen eron seuraavasti: järjestelmäohjelmointikieli Nämä kielet on tarkoitettu tietorakenteiden ja yksittäisten komponenttien toteuttamiseen siirrettävästi ja korkeammalla tasolla kuin assemblerilla kirjoitettaessa. Ne käyttävät vahvaa staattista tyypitystä. Järjestelmäohjelmointikieliä ovat esimerkiksi PL/I, Pascal, C, C++ ja Java. juontokieli Juontokielet olettavat, että on jo olemassa joukko hyödyllisiä komponentteja, jotka on kirjoitettu järjestelmäohjelmointikielillä. Juontokieliä käytetään komponenttien yhdistelemiseen, eräänlaisina liimoina (usein puhutaankin englanniksi glue language istä). Juontokielet käyttävät tyypillisesti dynaamista tyypitystä - tyypityksen vahvuus vaihtelee. (Ousterhout puhui tyypittömyydestä mutta hän tarkoitti dynaamista tyypitystä.) Juontokieliä ovat esimerkiksi Perl, Python, Rexx, Tcl, Visual Basic ja Unixin kuoret. Tehtävä 2 Ovatko edellämainitut järkeviä jaotteluja? Onko muita järkeviä jaotteluja? 12. John K. Ousterhout. Scripting: Higher-Level Programming for the 21st Century. Computer, vol. 31 no. 3, March 1998.

18 12 LUKU 1. JOHDANTO 1.4 Ohjelmointikielten suunnitteluperiaatteita Tony Hoare kirjoitti 1970-luvun alussa poleemisen artikkelin 13, jossa hän antoi mielestään objektiiviset kriteerit ohjelmointikielen hyvyydelle. Ne ovat seuraavat. Kielen tulisi auttaa ohjelman suunnittelussa. Kielen tulisi auttaa ohjelman dokumentoinnissa. Kielen tulisi auttaa virheiden jäljittämisessä. Näiden pohjalta Hoare nimeää viisi avainlausahdusta, jotka kuvaavat hyvää ohjelmointikieltä: yksinkertaisuus Yksinkertaisuus on välttämätöntä, sillä muuten edes kielen kehittäjä ei voi arvioida tekemiensä valintojen seurauksia eikä kielen toteuttaja voi saavuttaa edes luotettavuutta saati sitten tehokkuutta ja nopeutta. Yksinkertaisuudesta hyötyy kuitenkin ensisijaisesti kielen käyttäjä. turvallisuus Turvallisuudella Hoare tarkoittaa sitä, että kielellä kirjoitettu ohjelma ei saa missään tilanteessa edes ohjelmoijan virheen seurauksena käyttäytyä hallitsemattomasti (esimerkiksi sekoittaa käyttöjärjestelmän tai muistinhallinnan tietorakenteita) tai eri järjestelmissä eri tavoilla. Lisäksi kielen syntaksin tulee olla sellainen, ettei yksinkertainen kirjoitusvirhe muuta ohjelman merkitystä merkittävästi. Nykyisinä Internet-ohjelmoinnin aikoina turvallisuus on entistä merkittävämpi, sillä juuri ohjelmointikielten turvallisuuden puute on ollut merkittävä tietomurtoja edistävä tekijä. lyhyt kääntymisaika Käännösajan (se aika, joka kestää koodin muuttamisen päättymisestä siihen, kun muutettua ohjelmaa voi ajaa) tulee olla mahdollisimman lyhyt, jotta virheenjäljitys ja -korjaus onnistuisi mahdollisimman hyvin. Tämä vaikuttaa myös kielensuunnittelijan työhön, sillä eri ominaisuudet vaativat eri määrän työtä käännösaikana. ajonaikainen tehokkuus Ohjelmointikieli on työkalu ja siksi sen tulee olla tehokas. Tässä pätee sama kuin edellisessäkin kohdassa: kielensuunnittelija voi vaikuttaa paljon siihen, että onko hänen kielensä toteutettavissa tehokkaasti. luettavuus Ohjelman luettavuuden tärkeyden pitäisi olla kaikille selvä. Hoare antaa myös artikkelissaan monia ohjeita siitä, miten hänen mielestään näihin tavoitteisiin voitaisiin päästä, mutta monet niistä ovat jo varsin kyseenalaisia. Silti kielensuunnittelusta kiinnostuneen kannattaa tutustua Hoaren artikkeliin kokonaisuudessaan. 13. C. A. R. Hoare. Hints on programming-language design, emt.

19 1.5. KIELEN MÄÄRITTELY 13 Hoaren listaan voimme lisätä vielä yhden avainlausahduksen: stabiilius. Tuotantokäytössä olevan kielen tulee olla saavuttanut tietynasteinen kypsyys. Kielen käyttäjien tulee voida luottaa siihen, että juuri se kielen versio on validi vielä kahden, viiden ja aika usein vielä kymmenenkin vuoden kuluttua sekä ei pelkästään Windowsissa vaan myös Unixissa, Macissa ja vaikkapa GNU:ssa. Tässä auttaa voimakkaasti kielen standardointi, sillä standardi antaa stabiiliutta ja antaa yhteisen pohjan kielen eri toteutuksille. Tehtävä 3 Ovatko nämä kriteerit tarkoituksenmukaisia? Ovatko ne kattavia? Mitä sinä pidät tärkeänä ohjelmointikielessä? Tehtävä 4 Löydätkö vastaavuuksia ohjelmointikielen ja ohjelman hyvyyden arviointiin käytettävien kriteereiden väliltä? 1.5 Kielen määrittely Kielestä on aina syytä kirjoittaa määrittelydokumentti (specification) samaan aikaan kun sitä ensimmäistä kertaa toteutetaan tai heti sen jälkeen. Määrittelydokumentti kertoo ohjelmoijalle, mitä kieli tarjoaa, ja toteuttajalle, mitä hänen ohjelmansa tulee tehdä. Tämän dokumentin lisäksi on toki hyvä olla ohjelmoijan opas erikseen, koska määrittelydokumentti on ollessaan hyödyllinen tavallisesti suhteellisen vaikealukuinen. Määrittelydokumentissa kuvataan kaikki oleellinen kielestä riittävällä tarkkuudella. Tässä on valittavissa monta tarkkuustasoa: voidaan esittää asia epämuodollisesti tai sitten hieman muodollisemmin. Kielioppi esitetään nykyisin lähes aina täysin muodollisesti käyttäen tiettyjä formalismeja (tavallisimmin Backus-Naur Form (BNF) tai sen muunnokset EBNF ja ABNF). Merkitysoppi on tapana ilmaista sanallisesti, koska olemassaolevat merkitysopin muodolliset kuvausmenetelmät (aksiomaattinen, denotationaalinen ja operationaalinen) ovat varsin vaikeita kirjoittaa ja lukea. Myös mahdollinen tyyppijärjestelmä voidaan kuvata muodollisesti esittelemällä se päättelysääntöjoukkona. Palaamme näihin kaikkiin formalismeihin myöhemmin. Uuden ohjelmointikielen määrittelydokumenttia levitetään tavallisimmin kielen alkuperäisen toteutuksen mukana. Toisinaan erityisesti yliopistoissa ja tutkimuslaitoksissa luotujen kielten määrittelydokumentti julkaistaan laitosraporttina tai jopa kansainvälisenä tutkimusartikkelina, ja monien määrittelyjen nimi onkin muotoa Report on the X Language Y, missä X on jokin kieltä Y kuvaava lausahdus. Tavallista on myös julkaista kielten paranneltuja versioita,

20 14 LUKU 1. JOHDANTO jolloin saattaa tulla kyseeseen julkaista myös Revised Report on the X Language Y. Scheme on tästä mainio esimerkki: Scheme-raportista on nyt voimassa viides revisio 14. Kun kieli on saavuttanut tietyn kypsyystason ja käyttäjäjoukon, aletaan tavallisesti puuhata sen standardointia. Standardointia harrastavat monet järjestöt, tärkeimpinä ISO (kansainvälinen standardointijärjestö, ch/), usein yhteistyössä IEC:n (kansainvälinen sähköteknillinen standardointijärjestö, kanssa, ECMA (informaatio- ja kommunikaatojärjestelmiä standardoiva eurooppalainen järjestö, sekä IEEE (Institute of Electrical and Electronics Engineers, Takavuosina merkittävässä asemassa olivat myös Yhdysvaltain kansallisen standardointijärjestön ANSI:n standardit, mutta nykyisin lähes kaikki ohjelmointikieliin liittyvät ANSI-standardit ovat myös kansainvälisiä ISO/IEC-standardeja. Usein tosin kielten standardointi tehdään näiden virallisten tahojen ulkopuolella (esimerkiksi Haskell-kielen standardointi tehtiin käyttäjä- ja toteuttajayhteisön sisällä kyseinen standardi julkaistaan kirjana kohtsillään). Seuraavassa on listattu joidenkin tunnettujen kielten standardit: C-kielestä on kolme standardia: ANSI X , ISO/IEC 9899:1990 ja ISO/IEC 9899:1999. Kaksi ensimmäistä ovat oleellisesti sama standardi ja käsittelevät sitä C:n versiota, jota on tapana kutsua ANSI C:ksi, C89:ksi tai C90:ksi. Kolmas standardi käsittelee C:n uutta versiota C99:ä. C++-kielen standardi on ISO/IEC 14882:1998. Scheme-kielen standardi on IEEE Std C#-kielen standardi on ECMA-334. BASIC-kielestä on neljä standardia: ANSI X , ECMA-116, ANSI X (R1998) ja ISO/IEC 10279:1991 (E). Ne kaikki käsittelevät hieman eri versiota kielestä. Java-kielestä ei ole standardia. 1.6 Toteutustekniikoista Ohjelmointikielten toteutukset jaetaan kahteen pääluokkaan: on tulkkeja (interpreter) ja kääntäjiä (compiler). 14. Richard Kelsey, William Klinger ja Jonathan Rees (toimm.). Revised Report on the Algorithmic Language Scheme. ACM SIGPLAN Notices, vol. 33 no. 9, September 1998.

21 1.6. TOTEUTUSTEKNIIKOISTA 15 Rajanveto näiden luokkien välillä on hankalaa. Räikeimmissä tapauksissa se on suhteellisen helppoa: tulkki lukee ohjelmatekstiä ja suorittaa sitä lukiessaan, kääntäjä tuottaa ohjelmatekstistä konekielisen version, joka ajetaan erikseen. Käytännössä kuitenkaan puhtaita tulkkeja ei ole. Varsin suosittu tapa toteuttaa tulkki on rakentaa se kaksivaiheiseksi. Tulkkiin sisältyy eräänlainen esikääntäjä, joka kääntää ohjelman jonkin kuvitteellisen koneen konekielelle. Tämä kuvitteellinen eli virtuaalinen kone on suunniteltu siten, että sille on kyseinen kieli helppo kääntää ja toisaalta sitä on helppo simuloida ohjelmallisesti. Tulkin toinen osa on sitten tämän virtuaalisen koneen simulaattori, jota usein sanotaan virtuaalikoneeksi, joka sitten tosiasiassa tulkkaa tuon käännetyn tuloksen. Tämän virtuaalisen koneen konekieli on eräänlainen välikieli, jota tulkki käyttää apunaan. Sitä kutsutaan toisinaan tavukoodiksi (bytecode). Ohjelmointikielten kääntäjän (ja virtuaalikoneratkaisua käyttävän tulkin esikääntäjäosan) perusrakenne on kaksijakoinen: sillä on lähdekielestä riippuva etupää ja kohdekielestä (kohdekoneen konekieli) riippuva takapää. Etupää koostuu neljästä vaiheesta: leksikaalinen analyysi, syntaktinen analyysi, semanttinen analyysi ja välikoodin (intermediate code) tuottaminen. Takapää koostuu optimoimesta ja tuloskoodin (object code) tuottimesta. Tavallisesti osa näistä vaiheista tapahtuu limittäin, ei erillisinä vaiheina välituloksineen. Kääntäjätekniikan (jota myös tulkeissa käytetään) perusteos on ns. lohikäärmekirja 15, mutta se on suhteellisen vanha ja keskittyy lähinnä käskykielten kääntämiseen. Uudempi, ihan kohtuullinen kirja on Andrew Appelin Modern compiler implementation in Java 16, josta on olemassa versiot myös C- ja MLkielille. Funktiokielten toteutusta käsittelee Peyton Jones Alfred V. Aho, Ravi Sethi ja Jeffrey D. Ullman. Compilers Principles, Techniques and Tools, Reading, MA, Addison-Wesley, Andrew W. Appel. Modern compiler implementation in Java, Cambridge, Cambridge University Press, Simon L. Peyton Jones. The Implementation of Functional Programming Languages, New York, Prentice Hall, 1987.

22 16 LUKU 1. JOHDANTO

23 Luku 2 Kielioppi Ohjelmointikieltä voidaan tarkastella monella tasolla. Jokaisella tasolla ohjelman jäsennys on edennyt askeleen pidemmälle. Päällimmäisenä on se, miltä kielellä kirjoitettu ohjelma näyttää tekstinä: se on jono merkkejä. Seuraavalla (leksikaalisellaq) tasolla ohjelma on jono sanasia (token). Konkreetin kieliopin (concrete syntax) tasolla ohjelma hahmotetaan puurakenteeksi, jonka lehtiä ovat sanaset ja jonka sisäsolmut edustavat ohjelman merkitysrakenteita. Konkreetista kieliopista päädytään abstraktiin kielioppiin (abstract syntax) poistamalla puurakenteesta epäoleellisia yksityiskohtia (kuten kaarisulkeiden käyttäminen aritmeettisten lausekkeiden ryhmittelyyn). Seuraava taso on staattinen merkitysoppi (static semantics), viimeinen taso on dynaaminen merkitysoppi (dynamic semantics). Neljää ensimmäistä tasoa (merkit, sanaset, konkreetti kielioppi, abstrakti kielioppi) sanotaan toisinaan yhteisesti ohjelmointikielen kieliopiksi (syntax). On olemassa ohjelmointikieliä, jotka eivät ilmaise ohjelmia merkkijonoina. Tällaisia ovat esimerkiksi Prograph ja Gzz:n Clangit 1. Tällaiset kielet käyttävät jotain aivan muuta kolmen ensimmäisen tason tilalla. Useimmat tällaiset, eitekstuaaliset kielet voidaan kuvata kuitenkin abstraktin kielioppinsa ja staattisen ja dynaamisen merkitysoppinsa osalta samaan tapaan kuin muutkin kielet. Emme puutu näihin kieliin tässä luvussa. Tämän luvun tarkoituksena on tarkastella (tekstuaalisten) kielten kielioppia yleisesti. Käsittelemme tavat määritellä täsmällisesti kaikki neljä tasoa ja tarkastelemme, minkälaisia ratkaisuja kahdella ensimmäisellä tasolla on tehty eri kielissä. Kahta jälkimmäistä tasoa tarkastelemme käyttäen lausekekielioppia esimerkkinä. 1. Antti-Juhani Kaijanaho ja Benjamin Fallenstein. Totally Different Structural Programming Programming Languages in ZigZag. An invited talk presented at the First International ZigZag Conference, part of ACM Hypertext Conference 2001 in Århus, Denmark on August 14,

24 18 LUKU 2. KIELIOPPI 2.1 Merkit Ohjelman teksti kirjoitetaan merkkijonona. Ohjelmointikielet määrittelevät joukon merkkejä, joita voidaan käyttää ohjelmien kirjoittamiseen. Tavallisesti rajoitutaan ECMA-6 IRV -merkistöön 2 (tunnetaan paremmin nimellä ASCII). Tällöin käytettävissä ei ole mm. ääkkösiä. Monet kielet sallivat jonkin tuon merkistön laajennuksen käyttämisen merkkijonovakioissa, mutta esimerkiksi muuttujannimet ja avainsanat ovat rajoitettuja ASCII:hin. Joistakin kielistä on olemassa kaksi eri versiota, jotka eroavat toisistaan merkistön puolesta. Ensimmäinen tällainen kieli oli Algol, josta määriteltiin referenssiversio, joka oli suunniteltu ohjelmien painamista varten (esim. lehteen), ja kukin toteuttaja määritteli siitä kovoversion, jolla ohjelmat voitiin kirjoittaa koneelle. Esimerkiksi referenssiversiossa saatettiin lihavoida avainsanat, kun hardwareversiossa avainsanat saatettiin aloittaa pisteellä. Jotkin uudemmat ohjelmointikielet ovat ottaneet käyttöön ISO merkistön (tunnetaan paremmin nimellä Unicode), jolla voidaan periaatteessa ilmaista mikä tahansa käytössä oleva merkki (ja joitakin historiallisia merkkejä): ääkkösten lisäksi Unicodella voidaan kirjoittaa kiinaa ja jopa matematiikkaa. Useimmat tällaiset kielet sallivat koko Unicode-repertuaarin käyttämisen merkkijonoissa ja myös osan Unicode-merkistöstä käyttämisen muuttujannimenä. Silti useimmat rajoittuvat Unicoden ASCII-osajoukkoon avainsanojensa ja muun sellaisen osalta. 2.2 Sanaset Sanasiksi (token) sanotaan kielen pienimpiä merkityksellisiä rakenneosia. Tyypillisissä ohjelmointikielissä sanaset jakautuvat nimiin (identifiers), avainsanoihin (keywords), operaattoreihin, välimerkkeihin (punctuation) ja literaaleihin. Monissa kielissä on vielä lisäksi erillisenä sanasluokkana tyypinnimet (type names). Nimet ovat tavallisesti epätyhjiä merkkijonoja, jotka alkavat kirjaimella ja muodostuvat tavallisesti kirjaimista ja numeroista. Jotkut kielet sallivat nimissä myös joitakin muita merkkejä (alaviiva ja dollarinmerkki ovat yleisiä). Joissakin kielissä kirjainten koko merkitsee: auto ja Auto ovat joissakin kielissä eri nimiä, joissakin kielissä sama nimi. Yleensä nimeksi katsotaan pisin merkkijono, joka voidaan tulkita nimeksi (esimerkiksi merkkijonossa auto kissa on tavallisesti tulkittuna kaksi nimeä, auto ja kissa) Bit coded Character Set. Standard ECMA-6. ECMA-006.HTM, 1991.

25 2.2. SANASET 19 Se, mikä lasketaan kirjaimeksi ja mikä ei (ja, jos kielessä ei kirjainkoolla ole merkitystä, mitkä kirjaimet katsotaan toistensa kokovariaatioiksi), vaihtelee. Useimmat kielet lähtevät englannin kielen säännöistä: kirjaimia ovat englannin kielen aakkoset. Jotkin uudemmat kielet hyväksyvät kirjaimiksi myös ISO merkistön sisältämät kirjaimet, myös ääkköset. Unicode-standardi 3 määrittelee nimet ohjelmointikielestä riippumatta käyttäen Unicoden merkkiominaisuuksia. Sen perusidea on yllämainittu: aloitetaan kirjaimella ja jatketaan kirjaimilla sekä numeroilla. Nyt tosin käsitteet kirjain ja numero ovat reilusti laajempia kuin aiemmin: näin määriteltynä esimerkiksi ja ovat sallittuja nimiä. Useimmat Unicodea käyttävät ohjelmointikielet käyttävät jotain muunnelmaa Unicoden nimimääritelmästä. Avainsanat ovat tavallisesti nimien näköisiä sanasia, joilla on jokin erityinen vakiomerkitys, joka on kiinnitetty kielen suunnitteluvaiheessa. Tavallisesti avainsanat ovat ns. varattuja sanoja, jolloin niitä ei voi käyttää missään muussa merkityksessä, mutta esimerkiksi Schemessä ei ole varattuja sanoja lainkaan. Mikäli avainsanat eivät ole varattuja sanoja, monimutkaistuu kielen toteuttaminen huomattavasti, ja joskus sillä kirjoitettujen ohjelmien luettavuus kärsii. Vai mitä sanoisitte seuraavasta PL/I -pätkästä: IF IF = THEN THEN = ELSE; ELSE ELSE = END; END Toisaalta varattujen sanojen ongelmana on se, että kielen laajentaminen on vaikeaa. Moni uusi ominaisuus tarvitsee oman avainsanansa, ja jos sitä varten luodaan uusi varattu sana, jokin aiemmin täysin toimiva ohjelma menee rikki (ei käänny enää uudessa versiossa). Tästä syntyy helposti kiusaus käyttää jo olemassaolevia avainsanoja uudestaan eri merkityksessä. Esimerkiksi C:n avainsanalla static on kaksi toisistaan täysin poikkeavaa merkitystä. Operaattorit muodostuvat tavallisesti erikoismerkeistä kuten +, <= ja &&. Niiden tehtävänä on toimia algebrallisissa lausekkeissa kahden tai useamman alilausekkeen välissä merkitsemässä näiden välistä operaatiota. Joskus myös avainsana voi toimia operaattorina. Useimmissa kielissä operaattorit on ennalta, kieltä suunnitellessa määritelty: uusia ei ohjelmoija voi ottaa käyttöön. Joissakin kielissä, kuten Haskellissa, operaattoriksi kelpaa mikä tahansa tietyistä merkeistä koostettu merkkijono, ja näiden operaattoreiden merkitys voidaan määrätä ohjelmassa. Välimerkkejä ovat sulkeet, aaltosulkeet, hakasulkeet, pilkut, puolipisteet ja muut sellaiset merkit, jotka eivät kuulu mihinkään muuhun kategoriaan mutta joilla 3. The Unicode Consortium. The Unicode Standard, Version is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, ISBN ), as amended by the Unicode Standard Annex #27: Unicode 3.1 ( and by the Unicode Standard Annex #28: Unicode 3.2 (

26 20 LUKU 2. KIELIOPPI on kuitenkin erityinen, kielen suunnittelun aikana kiinnitetty merkitys. Varsin yleistä on, että joissakin kielissä osaa välimerkkien tehtävistä hoitaa jokunen avainsana ja päinvastoin (esimerkiksi vertaa Pascalin begin- ja end -avainsanaa C:n aaltosulkeisiin). Literaalit ovat ohjelmaan kirjoitettuja vakioita, jotka edustavat tiettyjä vakioarvoja. Useimmat ohjelmointikielet tukevat merkkijonoliteraaleja ("..."), kokonaislukuliteraaleja (12345), liukulukuliteraaleja (3.0e2) ja merkkiliteraaleja (... ). Literaalien rakenne on varsin samanlainen eri kielissä. Monissa kielissä (kuten C) on erikseen sanaskategoria tyypinnimille. Tämä johtuu siitä, että näiden kielten konkreetin kieliopin toteuttaminen olemassaolevalla, tehokkaalla jäsennysteknologogialla olisi muuten hankalaa. Joissakin kielissä (kuten Haskell) tyypinnimet on tunnistettavissa eroon tavallisista nimistä jollakin nimen muotoon liittyvällä piirteellä: esimerkiksi Haskellissa tyypinnimet alkavat isolla alkukirjaimella ja muut nimet pienellä alkukirjaimella. Moinssa kielissä (esimerkiksi kaikki C-sukuiset) tyyppinimien tunnistamiseen tarvitaan yhteistyötä leksikaalisen ja konkreetin kieliopin tasojen välillä: kun konkreetissa kieliopissa havaitaan, että nyt määritellään uusi tyypinnimi, tämä tyypinnimi kerrotaan leksikaaliselle tasolle. Sanasten välissä on toisinaan tyhjää. Useimmissa kielissä tyhjämerkit (whitespace) jätetään huomiotta paitsi silloin, kun sitä tarvitaan erottamaan eri sanaset toisistaan. Tällaiset kielet ovat vapaamuotoisia (free-form). Aivan ohjelmoinnin alkuaikoina, esimerkiksi Fortranissa, oli välttämätöntä sijoitella ohjelman eri osat tiettyihin kohtiin, jolloin välilläkin oli väliä. Joissakin nykykielissä (esim. Python ja Haskell), tyhjämerkeillä osoitetaan ohjelman rakenne niin, että mitään erityisiä välimerkkejä sitä osoittamaan ei käytetä. Ohjelmointikielten leksikaalinen taso on yleensä mahdollista määritellä säännöllisenä kielenä (regular language) ja useimpien kielten ohjelma on mahdollista jakaa sanasiin käyttämällä sopivaa äärellistä automaattia. 2.3 Muodolliset kieliopit Ohjelmointikielten konkreetti ja abstrakti kielioppi määritellään yleensä täsmällisesti käyttämällä yhteydettömien kielioppien (context-free grammars) käsitteistöä. Abstrakti kielioppi ilmaistaan tavallisesti puhtaasti muunnossäntöinä (rewrite rules, productions):

27 2.3. MUODOLLISET KIELIOPIT 21 Tässä ja ovat välikesymboleja (nonterminal symbols) ja,, ja ovat päätemerkkejä (terminal symbols). Välikesymboli edustaa literaalisanasta, jonka rakennetta ei ole tässä kuvattu. Tärkeää tässä on huomata, että tämä kielioppi on moniselitteinen (ambiguous) se ei kelpaisi merkkijonon jäsentämiseen. Siihen se ei ole tarkoitettukaan: tämä kielioppi on abstrakti, se kuvailee nelilaskimen lausekkeiden oleelliset osat, ei kaikkea sitä, jota niiden kirjoittamiseen merkkijonona tarvitaan. Oikeastaan abstrakti kielioppi kuvaa tietorakenteen, jossa tällaiset lausekkeet voidaan esittää havainnollisesti. Saman asian konkreetti kielioppi on yksiselitteinen ja varsin sotkuinen: Edellä käytettyjen merkintöjen lisäksi tässä esiintyy kaksi uutta välikesymbolia ( ja ) seka kaksi uutta päätemerkkiä (aaltosulkeet). Konkreetti kielioppi ilmaistaan yleensä käyttäen John Backusin ja lukujen vaihteessa kehittämää merkintätapaa, jota Peter Naur kehitti edelleen ja käytti Algol 60:n määrittelydokumentissa, nimittäin BNF:ää (Backus Naur form, ei Backus normal form 4 ) tai jotain sen muunnelmaa. BNF:llä ilmaistuna ylläoleva kielioppi kirjoitetaan seuraavasti: 4. Donald E. Knuth. Backus Normal Form vs. Backus Naur Form. Communications of the ACM (letters to the editor), vol. 7, no. 12, December 1962.

28 22 LUKU 2. KIELIOPPI Expression Term Factor Term Factor Literal Expression Term Factor Expression Term Term Expression Factor Term ISO ja IEC standardoivat vuonna 1996 laajennetun version BNF:stä 5, EBNF:n. EBNF laajentaa BNF:ää lisäämällä siihen tuen valinnaisuuden, toiston, ryhmittelyn, määräkertaisen toiston ja poikkeustapausten ilmaisemiseen. EBNF sallii välikesymbolin koostua useammasta sanasta. Lisäksi EBNF sallii kommenttien lisäämisen kieliopin kuvaukseen. Internet-protokollien määrittelyissä käytetty BNF:n muunnelma (Augmented BNF eli ABNF) on myös standardoitu: RFC on syntaktisen metakielen ehdotettu Internet-standardi (Proposed Standard). 2.4 Jäsennyspuut Konkreetin kieliopin voi ajatella kuvaukseksi, joka kuvaa merkkijonoja (tai sanasjonoja) järjestetyiksi puiksi. Näiden puiden sisäsolmut ovat välikesymboleita ja lehtisolmut päätemerkkejä (sanasia). Tällaisesta ns. jäsennyspuusta (parse tree) voidaan lukea koko merkkijono (sanasjono) käymällä puu läpi järjestyksessä ja merkitsemällä kukin kohdattu lehtisolmu ylös. Kunkin (epätriviaalin) alipuun juuri (joka on alkuperäisen puun sisäsolmu) kertoo, mitä välikesymbolia kyseinen puu vastaa. Kuvassa 2.1 kuvataan erään aritmeettisen lausekkeen jäsennyspuu edellä annetun konkreetin kieliopin mukaan. Abstrakti kielioppi puolestaan kuvaa lausekkeen mielekkäiden osien suhteita. Oikeastaan abstrakti kielioppi on rekursiivisen tyypin kuvaus, joka kertoo, että minkälaisia tämän kielen abstraktit jäsennyspuut ovat. Esimerkiksi sivulla 21 annettu abstrakti kielioppi vastaa oleellisesti seuraavia Haskellmäärittelyjä: data E = E : E E : E E : E E : E Literal L 5. Information lechnology Syntactic metalanguage Extended BNF. International standard ISO/IEC 14977:1996(E),