4. PROGRAMOZÁSI PARADIGMÁK, PROGRAMOZÁSI NYELVEK

Átírás

1 4. PROGRAMOZÁSI PARADIGMÁK, PROGRAMOZÁSI NYELVEK Bizonyára elgondolkodott már a nyájas olvasó, miért van annyi programozási nyelv a világon. Szerény becslések szerint csak a használatban lévő programozási nyelvek száma meghaladja a 4000-et. Vajon mi az oka ennek? A számítástechnikai szakembereknek az a hajlama, hogy minden probléma számítógépes megoldására a legmegfelelőbb programozási nyelvet kívánják használni, s miután a megoldandó problémák száma meglehetősen nagy, a programozási nyelvek száma is nagyra nőtt? Vagy egyszerűen a profit, a haszonszerzés, azaz, hogy újabb és újabb programozási nyelveket, fejlesztő rendszereket szeretnének eladni? Valóban szükség van ennyi nyelvre? Különböznek a programozási nyelvek oly mértékben, hogy azok valóban mások és mások? Nos, szabványosításra sokkal kevesebb nyelv került, mint amennyit használtak már a történelemben. Továbbá, az utóbbi időben már lassabbodott a nyelvek számának rohamos növekedése. A szoftver krízis, a minőség iránti igény növekedése, és ebből fakadóan a szoftver újrafelhasználás gondolatkör eredményezték ezt a lassulást. Mindenesetre, szeretnénk rendet csinálni ebben a nyelvi Bábelben. Szeretnénk a nyelveket áttekinteni, osztályozni. Szerencsénkre a programozási nyelvek szimbólumkészleténél, megjelenésénél, még a nyelvtani szabályainál is sokkal fontosabbak a nyelv mögötti gondolatok. Ezek maradandóbbak, kevésbé változatosak, tovább élnek. A mögöttes gondolatok és elképzelések megismerése segíti a számítástechnikával ismerkedőket, hogy egy-két nyelv elsajátítása után már nem jelent gondot egy-egy újabb programozási nyelv akár önerőből való megtanulása sem A PROGRAMOZÁSI PARADIGMA FOGALOM Egy kis történelem, paradigma váltások A programozási nyelvek történetét együtt szokás tárgyalni a hardver fejlődéssel és a működtető rendszerek fejlődési trendjével. Kétségtelen az összefüggés

2 2 PROGRAMOZÁSI PARADIGMÁK ezek között, most mégis kíséreljük meg a programozási nyelvek, a programozási módszerek fejlődését áttekinteni. Bal és Grune [Bal&Grune, 1994] évtizedeket különböztet és nevez meg e históriában. A múlt század negyvenes évei képezték a nyelvnélküli világot. A számítógép tervezők, építők, a felhasználók még ugyanazon a személyek voltak, a gépi programozást még assembly fejlesztő rendszer sem segítette. Az ötvenes években már voltak számítógép gyártó és tőlük különböző felhasználó intézmények, de a hardveres és szoftveres feladatkörök, a rendszerprogramozói, programozói és felhasználói munkakör még nem vált szét. Már növekedett a gépek teljesítménye, de az igen szűk kapacitások miatt a számítógépes művészet csúcsa a minél kisebb, minél hatékonyabb kód megírása volt. Megjelent az assembly és a Fortran nyelv. A hatvanas években kezdtek a nyelvek sokasodni. Már nem volt akkora gond a számítási erő, a memória persze, nem a mai viszonyokhoz kell ezeket hasonlítani. A programok kifejező ereje növekedett, ez a jellemzője a kornak. A hetvenes években jelentkezett a szoftver krízis. A programok túlnyomó része nem futott, gondok voltak a program helyességgel, a gépfüggetlenséggel. A nyolcvanas években megkíséreltek válaszolni a kihívásokra. Strukturált programozás paradigmája volt a válasz. A kilencvenes évek paradigmája, alapja az objektum orientáltság. Máig nagy a hatása, bár a mai időket a Web programozás paradigma jellemzi. Érdemes pillantást vetni az évtizedek egysoros jellemzésére: 40-es évek 50-es évek 60-as évek 70-es évek 80-as évek 90-es évek Ma A nyelvnélküli világ: ha egy program fut, az jó program Használd ki! Meg tudod írni egy instrukcióval kevesebbel? Kifejező erő! Nézd, ez az egysoros program mit meg nem csinál! Csökkentsd a gépfüggőséget! Nézd a program helyességét! A komplexitás a gond. Strukturált programozás. A szoftver újra felhasználás. Objektum orientált a világ. Web programozás. Amit hangsúlyozni szeretnék itt, az a következő, a programozási nyelvek fejlődését ún. paradigmaváltások kísérték. A fejlődési szakaszokat különböző paradigmák alapozták meg. Ha osztályozni akarjuk a programozási nyelveket, akkor a mögöttes gondolatukat meghatározó programozási paradigmák szerinti osztályozás jó gondolat lehet. Persze, hogy megértsük ezt az osztályozást, nézzük meg, mit is jelent számunkra a paradigma kifejezés A paradigma fogalma A paradigma kifejezésnek hosszú története van. A tudománytörténet során jelentése változott. A jelentése attól is függ, hogy milyen tudományterületre alkal-

3 PROGRAMOZÁSI PARADIGMÁK 3 mazzuk. Érdemes tehát meghatározni, hogyan is fogjuk mi értelmezni ebben a tárgyban. A paradigma kifejezés két ógörög szóból származik. Egyik szó a para (elnézést kérek, hogy nem a görög ábécét használom itt), jelentése körülbelül az, hogy hasonló, vagy egymásra utalt, vagy egymásmelletti. A paralelogramma szavunk első két szótagjáról van itt szó. A másik görög szó a deigma. Jelentése kb. ami be van mutatva. A paradeigma ógörög kifejezés a piacokon egymás mellett bemutatott árucikkeket jelentette. Volt egy olyan értelme, hogy bemutatási példány, bemutatási példa. Még mindig az ógörögöknél maradva, ahol a tanulás-tanítás módszere példák felsorolása volt, a paradigma kifejezés olyan értelmet nyert, hogy oktatási céllal bemutatott példát, példázatot jelent a paradigma szó. A társadalomtudományokban ma is felfedezhető ez a fajta jelentés. A természettudományokban azonban jelentésváltozáson ment át a szó. A tanítási példa jelentés helyett inkább az elméletet igazoló példa jelentést kezdte felvenni. A középkorban pl. a bolygók mozgásával igazolták a mechanikai törvényszerűségeket. A bolygók mozgásának paradigmája volt az elmélet igazolása. Egyegy jól választott példa az elmélet és módszer bizonyítása volt. A mai paradigma definíció a természettudományok területén is megtartva az eredetéből a minta, a mintául szolgálás mozzanatot, gazdagodott. Az idegen szavak szótára három jelentését adja. A paradigma bizonyításra, vagy összehasonlításra alkalmazott példa lehet (ez az eddigi levezetésünkből adódik), vagy ragozási minta lehet (ebben is szerepel a minta gondolata, de ez egy szűkített jelentés), illetve az adott korszakban elfogadott általános tudományos tételek együttese; a kor tudományos világképe. Utóbbit a társadalomtudományok használják, és túl általános a jelentésük. A mi meghatározásunkhoz közelítve két mai definíciót idézek. Az egyik [Erdélyi et al, 1997] szerint a paradigma olyan átfogó szabályok, adatok és adatstruktúrák együttese, amely összetett, dinamikus tevékenységi kör számára mintául szolgál. Követése jó (vagy nem túl rossz) döntések meghozását segíti. A másik [Kuhn, 1970] szerint a paradigma koherens módszerek együttese, mely összetett problémakör kezelését hatékonnyá teszi, azzal, hogy mintául szolgál. A definíciók jók, használhatók. Talán azzal lehetne ezeket kiegészíteni, hogy paradigma olyan összefüggő módszerek, szabályok és adatok együttese, melyek követése, használata hatékony lehet egy adott probléma tartomány adott problémájának megoldására. A paradigmák jellemezhetők, megragadhatók egy nagyon egyszerű, de roppant kifejező erejű princípiummal. Ez a jellemző egyszerűen megfogalmazható és a paradigmának meggyőző erőt adhat. A kifejező erejű alapelv mellett természetesen kellenek módszerek és technikák is, melyek persze nem mondhatnak ellent a röviden megfogalmazott alapelvnek. Miért jók, miért szükségesek a paradigmák? Nos, a bonyolult rendszereket nagyon nehéz modellezni. Főleg ott, ahol az ember is része a rendszernek, ahol emberi döntésekre is szükség van, a modellezés és determinisztikus optimalizálás lehetetlen. Meggyőző mintákat követve azonban juthatunk eredményre. Gond is van persze, ha paradigmákat követve akarunk megoldani problémákat. Egyik gond a túlegyszerűsítés kísértése. Miután a paradigmát jellemzi az a bizo-

4 4 PROGRAMOZÁSI PARADIGMÁK nyos meggyőző erejű, egyszerű alapelv, követése során hajlamosak lehetünk a túlzott egyszerűsítésre, egysíkú magyarázatokra. Ennek a veszélynek mindig tudatában kell lennünk. A másik gond az, hogy egy paradigma csakis akkor mondható paradigmának, ha van legalább néhány követője. A paradigmát, a jellemző alapelvét el kell fogadni. Kell, hogy legyenek követői, támogatói a paradigmának. A paradigma valóban meggyőző kell legyen Programozási paradigmák A programozás ma még emberi tevékenység. Mint emberi tevékenység, meglehetősen bonyolult. Lehet bizonyos mértékig modellezni, tervezni, de, mivel emberek programoznak, determinisztikus modellezése biztosan lehetetlen. Paradigmák szerinti megközelítése azaz programozási minták, módszerek és technikák követése szerinti ígéretes lehet. Szokták is ezért tárgyalni a programozási paradigmákat. Szuromi Zsolt [Szuromi,1996] például egy sor programozási paradigmát tárgyal. Szerinte van monolitikus programozás, strukturált programozás, imperatív programozás, applikatív programozás, objektum orientált programozás, konkurens programozás. Mi, jelen tárgyban az imperatív, a funkcionális, a logikai és az objektum orientált programozás paradigmáit tárgyaljuk. Az imperatív program lényege az, hogy lépésenként végrehajtott módú, teljesen specifikált és kontrollált manipulációkat adjunk meg a programban, teljesen specifikált (névvel ellátott) adatokon (fully specified and fully controlled manipulation of named data in step-wise fashion). A funkcionális programozás során a programozó inkább azt specifikálja a programban, mit kell kiszámítani, nem az, hogy hogyan, milyen lépésekben. (Kifejezésekből álló) függvények hívásából, ezek kiértékeléséből áll a program. Nincsenek állapotok, mellékhatások (nem számít, mikor, csak az melyik függvényt hívjuk). (Referential transparency.) Nincs értékadás, csak érték-kiszámítás. A logikai programozási paradigma szerint a programozó if-then szabályokat és tényeket fogalmaz meg, és a rendszer automatikusan kikövetkezteti (infer) ebből, hogy egy adott feltétel igaz-e vagy sem. Ha a tényekből és a szabályokból az következtethető ki (automatikusan), hogy a feltétel igaz, akkor ez a feltétel bizonyított (proved). Az objektum orientált programozás paradigmája nem is egyszerűen követendő programozási stílus, hanem tervezési módszer, modellezési módszer, szemléletmód is egyben. Ebben az adatmodell és az eljárásmodell szétválaszthatatlan (egységbezárás). Az újrafelhasználhatóság elvét kiterjeszti, ameddig csak lehetséges (öröklődés). Az információrejtés és szabályozott elérés a programozás minőségét növeli. A többalakúság teszi lehetővé, hogy ugyanarra az üzenetre a különböző objektumok a saját módjukon válaszoljanak. Miután összefoglaltuk a tárgyalandó paradigmák lényegét, nézzük a paradigmákat részletesen!

5 PROGRAMOZÁSI PARADIGMÁK AZ IMPERATÍV PROGRAMOZÁSI PARADIGMA Az imperatív programozási stílus alakult ki a számítástechnika történetében legelőször. Ennek számos oka volt. A Neumann elvű gépek programozásának ez a stílus felel meg igazán, máig ez a programozási módszer a leghatékonyabb, a nyugati ember gondolkodásmódjának nagyon megfelel ez a programozás. Miután a kezdetben tisztán Neumann elvű számítógépek voltak, és sok tekintetben a mai gépek is ennek az elvnek felelnek meg, nem csodálható az imperatív paradigma kezdeti és bizonyos területeken a mai sikere. Voltak ugyan kísérletek idővel, hogy változtassanak az imperatív programozás elsöprő fölényén, a Prolog törekvések, vagy a japánok ötödik generációs számítógép rendszere ilyenek voltak, de nem hoztak áttörést ezek a kísérletek. Véleményem szerint ennek elsődleges oka a teljesítmény előny: egy imperatív program sokszorosan gyorsabb, kisebb hardver kapacitással megelégszik. Manapság az objektum orientált programozási paradigma kél versenyre az imperatív párjával. Valószínű az OOP térnyerése, azonban az imperatív nyelveket teljességgel sohasem fogja kiszorítani. Az imperatív programokra kisebb hardver kapacitásoknál mindig szükség lesz. Mikor az imperatív programozás jelentőségét ennyire hangsúlyozom, természetesen nem akarom lebecsülni a többi programozási paradigmát. Mindegyiknek meg lehet találni a saját problémakörét, azt a problémakört, melyben az adott paradigma hozhatja az optimális eredményt (ahol az optimum kritérium nem valószínű, hogy a gyorsaság lesz). Az imperatív programban lépésenként megadják, hogy mit kell tenni és milyen adatokkal. Pongyolán fogalmazva, olyan egy imperatív program, mind a szakácskönyv. Először felsorolják a hozzávalókat (deklarációkkal teljes specifikációt adnak az adatokról), majd lépésekben megadják az eljárást, mit kel tenni először, hogyan kell folytatni a dolgot, esetleg ismételni kell valamely lépéseket, esetleg választani kell, hogyan is folytassuk a munkát. Ez a fajta program, egy tevékenységsorozat leírása, megadása az atlanti embertípustól nem idegen. Ismét komolyra fordítva a szót, az imperatív paradigmának nagyon sok programnyelv megfelel. Csak néhányat említek meg a legjelentősebb és legelterjedtebb imperatív nyelvek közül. Elsőnek a C nyelvet, de imperatív jellegű az ADA, a Pascal, a Modula-2, a különféle Basic nyelvjárások, és a még ma is használatos FORTRAN és COBOL is e családba tartozik. És említsük meg, hogy a objektum orientált programnyelvek bár mást hangsúlyoznak, mint a tedd ezt, utána ezt és ezt lépéseket belül megtartottak sokat az imperatív gondolatból. Metódusaik belül lépésenkénti teendőket tartalmaznak. Mint említettük, az imperatív paradigma alakult ki történelmileg először. A gépi kódú programozásról ahol a hardver egyre magasabb szintű absztrahálásáról volt csak szó áttérve a magasabb szintű nyelvekre egyre többet kezdtek foglalkozni az adat-típusokkal és a programvezérlés menetével. Beláthatjuk, hogy az imperatív paradigma éppen az adattípusokat és a vezérlés menetét próbálja megragadni.

6 6 PROGRAMOZÁSI PARADIGMÁK Foglaljuk össze röviden és velősen az imperatív paradigma lényegét, hiszen ha paradigma a koncepció, akkor meg lehet fogalmazni röviden és meggyőzően ezt a lényeget A paradigma Az imperatív paradigma szerint egy programban teljesen specifikált nevezett adatokon lépésenkénti végrehajtással adottak a teljesen specifikált manipulációk. Figyeljük meg, a definícióban három dolgot jelentettünk ki. Az első (amit fent a harmadikként jelentettünk ki) az, hogy teljesen specifikáltak az adatkezelési manipulációk, számítások, döntések. Minden utasítás, operáció előre megadott, rögzítettek a környezeti feltételei, adott az értelmezése. Másodszor azt jelentettük ki, hogy a manipulációk lépesekként vannak megadva. Ez a gondolat a programok vezérlési szerkezeteire hívja fel a figyelmet. Az utasítások végrehajtása lépésenként lehet soros egymásutániság (szekvenciális programszerkezetek), lehetnek ismételt lépések (ciklusok, ciklikus végrehajtási szerkezetek), és lehetnek választások a következő lépésre, melyik utasítás legyen a következő (elágazásos szerkezetek). A lépésenkénti utasítások, a tedd ezt, utána ezt és ezt jelleg adta a paradigma nevét: imperatív = parancsoló. Harmadszor (a definíciónkban ez volt az első) pedig azt mondtuk, hogy teljesen specifikált nevezett adatokon fognak történni a manipulációk. Nos, itt tehetünk engedményeket. A paradigma lényegének összefoglalása ebben szigorúbb, mint a paradigmának azért megfelelő valódi programozási nyelvek többsége. Azaz vannak nyelvek, melyek nem követelik meg a szigorú tipizálást (a teljes specifikációt), engedik a névnélküli adathasználatot (lexikális konstansokat). Az adatok specifikálását a programban a deklarációkkal tehetjük meg: Deklarációkkal adjuk meg a nevüket és a típusukat. A legtöbb az imperatív családba tartozó nyelv a változók deklarációját megköveteli a rájuk való első hivatkozás előtt. A változók ezzel nevet és típust nyernek. A típusuk meghatározza az értéktartományukat és a velük hiba nélkül végezhető operációkat. A program futtatásához az értéktartományuknak is megfelelő tárolási reprezentációt kell meghatározni. A tárolási reprezentáció mikéntje meg fogja adni memória helyfoglalás méretét is. Azok a nyelvek, melyek engedik az automatikus változódeklarációt (pl. ilyen a FORTRAN) valójában szintén biztosítják a teljes adatspecifikációt. Legfeljebb nem a programozó deklarálja ezeket a változókat, azok automatikusan deklarálódnak. Az általános vélemény szerint ez a kis programozónak adott kényelmi engedély meglehetősen nagy hibaforrás. A lexikális konstansok típusa szintén automatikusan deklarált., azaz a szövegkörnyezetből kideríthető. Ellentmondások persze itt is előfordulhatnak, növelve a programozói hibák előfordulásának lehetőségét, de a legtöbb nyelv létrehozója engedi a lexikális konstansok használatát a nyelvében. A továbbiakban két mozzanattal foglakozunk: a deklarációk-adatok világával és a programvezérlési szerkezetekkel. Nézzük ezeket sorban.

7 PROGRAMOZÁSI PARADIGMÁK Az adat deklarációkhoz A data (adatok) egy gyűjtőnév. Az adatok az információ hordozói. Az imperatív programozási nyelvekben az adatoknak van típusa. A típus tulajdonképpen egyfajta osztályozás (klasszifikáció). A legtöbb adatnak van neve, és a nevüket használjuk az adatokkal való manipulációkban. Az adatok a memóriában foglalnak helyet, ezért kell legyen címük a memóriában. Végül, minden adatnak van pillanatnyi értéke. Miután a memória változtatható, az adat értéke alapértelemben cserélhető. Ha a programozási nyelv engedi ezt a változtatást, akkor hívhatjuk ezt a nevezett adatot változónak. Az adatok típusa több mindent meghatároz. Megadja az adat felvehető értékkészletét, az adattal végezhető operációk készletét. Rendszerint a típus megadja a memóriabeli reprezentációt (a bitelrendezést, struktúrát) is, ezzel a memóriabeli helyfoglalási hosszat. Egy példán szeretném bemutatni a név, a típus, a reprezentáció és az érték között (4.1. ábra). Az ábrán az int típushoz tartozó értékkészlet és operációkészlet adott. E két attribútum a nyelvhez kapcsolódik, rendszerint a nyelv alkotói határozzák meg. A memóriabeli reprezentációt már a fordítóprogram írói is befolyásolhatják: rendszerint az adott hardverhez igazítva adják meg. Az ábránkon egy szokásos reprezentációt adunk: 16 bites helyfoglalással egy szavas egész számára. Az első bit az előjel bit, a többi a bináris kódolással adja az egész értéket. Az ábránkon az i változóhoz ezt az int típust rendeltük. Az i változó pillanatnyi értékét adó bitminta a 4 pillanatnyi értéket adja. Típus név int Típus, -1, 0, 1, 2, Értékkészlet +, -, *, /, Operációkészlet Reprezentáció s Változó név i Bitminta ábra. Kapcsolat a név, a típus, a reprezentáció és az érték között Az imperatív nyelvekben az adatokat deklarálni kell. A deklaráció az adatokhoz nevet és típust kapcsol (binds a name and type). Ezzel az adat ismertté válik. A puszta deklaráció (allusion) csak ismertté teszi az adatot. A definíciós deklaráció ismertté és használhatóvá teszi az adatot, azzal, hogy az adathoz memóriabeli címet is kapcsol. A legtöbb imperatív nyelvben lehetséges típus definíció is. Ez a definíció egy típushoz kapcsol nevet, amivel a típus válik ismertté és használhatóvá. Ne feledjük, hogy egy típus mindig megadja az értékkészletet és az operációkészletet, nos, egy típus definíciónál -- lehet persze, hogy nem kifejezetten, hanem csak beleértetten -- megadandó e két készlet.

8 8 PROGRAMOZÁSI PARADIGMÁK Tovább is általánosíthatunk! Egy nyelvben létezhet valamilyen entitás 1 deklaráció (ami ismertté tesz az entitást), illetve entitás definíció (ami használhatóvá is teszi az entitást. Az entitás szót használom itt, bár használhatnánk az objektum kifejezést is. Az utóbbit azonban az objektum orientált programozási paradigmának megfelelő nyelvek foglalják, ezért nem akarok keveredést. Az entitás az imperatív nyelvekben lehet név, típus, adat, operáció, rutin (eljárás vagy függvény) is. Hangsúlyozom, hogy az egyszerű deklaráció ismertté tesz egy entitást, míg a definíció használhatóvá is teszi azt. Előfordulhat, hogy a deklaráció egyben definíció is, de lehet előbb pusztán deklarálni, majd később definiálni ugyanazt az entitást. A leggyakoribb és legegyszerűbb példa erre a késleltetett definícióra az eljárások függvények deklarációja, definíciója. Gyakori ugyanis, hogy egy deklarált függvény aminek ismerjük a nevét és típusát -- definícióját nem is mi, a program írói adjuk meg, hanem az majd a futtatható program összeállításánál (a linkelés során) definiálódik a rutin. Úgy is szoktuk mondani, hogy a linkelés során oldódnak fel bizonyos függvénynevek. A 4.2. ábrán bemutatok két imperatív nyelvi változó deklaráció programrészletet. Az egyik nyelv az ismert C nyelv, a másik az ADA nyelv (ami szintaxisában nagyon hasonlít a Pascal nyelvre). C nyelv int i, j; int k=4, j=4; ADA nyelv I, J: Integer; K, L: Integer:=4; 4.2. ábra. Változó deklarációk A deklarációkban négy változót deklarálunk, az i, j, k és l változókat. Ne feledjük a deklaráció többes feladatát, azaz, hogy készíteni kell típusos adatot és definíciós deklaráció esetén memóriát kell allokálni neki, illetve, hogy kötni kell egy nevet a változóhoz! A definíciós deklarációk megengedik a változó feltöltését kezdeti értékekkel. Az ábrán az i és j (Az ADA nyelvben I és J) változók biztos kaptak nevet és típust. A k és (K és L) változók pedig, miután inicializáljuk is őket, biztos, hogy definiálódnak is. Úgy is mondhatjuk, hogy a definíciós deklarációkkal példányosítunk egy adott típust. Érdekes, hogy az ALGOL 68 nyelv szétválasztja a név és típus kapcsolást és a memória hely allokálást! A 4.3. ábrán a k változó definíciójában a ref int k kapcsolja a nevet és típust, míg a loc int allokálja a memóriahelyet. A := 4 szerkezet pedig kezdeti értéket ad a definiált változónak. 1 Entitás: lényeges létező valami

9 PROGRAMOZÁSI PARADIGMÁK 9 Algol 68 ref int k = (loc int := 4); 4.3. ábra Deklaráció az Algol 68-ban A legtöbb imperatív programnyelv megengedi a szövegkörnyezeti konstansokat (literális konstansok, literálok). Ezek névnélküli, de típussal és címmel rendelkező adatok, azaz ismert az érték- és operáció készletük, valamint a reprezentációjuk is. Mivel nincs nevük, egyszeri a hivatkozás rájuk: pillanatnyi értéküket adják ott, ahol a szövegben szerepelnek. Mind a típusuk és pillanatnyi értékük a szövegkörnyezetből deríthető ki, a fordítóprogramok a szövegből ismerik fel a literálokat. A fordító biztosít számukra memóriát is. A literálok címét rendszerint nem is érhetjük el programjainkban, szemben a névvel rendelkező entitásokkal: ezek címét legalább is némely programozási nyelvben elérhetjük. Némely nyelv megengedi a konstansok deklarációját is (4.4. ábra). Ez tulajdonképpen inicializációs (ezzel definíciós) változó deklaráció, ahol is a fordítóprogram külön szoftveres védelmet biztosít, nem engedi a konstans változót módosítani. Vagy azzal a megoldással, hogy bár a hardver képes lenne a módosításra, de nem engednek olyan kódot, ami módosítana, vagy eleve írásvédett memória szekcióba helyezik az ilyen változót. C nyelv const int k=4, j=4; ADA nyelv K, L: Constant Integer:=4; 4.4. ábra Konstans deklarációk A konstans deklarációk előnye, hogy hibalehetőségeket kerülhetünk el: fegyelmezettebb programozási stílus alakítható ki, ha minden adatot kifejezetten deklarálunk, a szövegben nem maradnak literális konstansok. Érdemes foglakozni az iniciálizálatlan változók problémájával. Több nyelv a C és az ADA is engedi, hogy memóriát foglaljunk, ugyanakkor kezdeti értéket kifejezetten ne adjunk változóknak. A kérdés az, hogy megjósolható-e ilyenkor a változó kezdeti értéke? Hibát okozhat ez a bizonytalanság. A nyelvek fejlesztői különböző válaszokat adhatnak. A legegyszerűbb bár nem elegáns válasz az, hogy a programozóra hárítják a felelősséget. Másik válasz szerint minden típushoz tartozik egy speciális, a nyelv fejlesztői által adott inicializáló érték, és a kifejezett kezdeti értékadás nélküli deklaráció során ezt az értéket veszi fel a változó. Egy harmadik válasz szerint egyes típusú változók automatikusan felveszik a speciális inicializáló értéket, mások pedig nem, azok titokban inicializálódnak. Tulajdonképpen ismét a programozóé minden felelősség, ráadásul még a könnyelműségre csábítják is. A titokban inicializálódás azt is jelentheti, hogy egy változó a neki allokált memóriaterületen maradt, nem törölt bitmin-

10 10 PROGRAMOZÁSI PARADIGMÁK tázat szerint kapja a kezdeti értéket. Súlyos biztonsági kockázatot jelent ez. Végül, lehetséges bár költséges megoldás, ha a fordítóprogram figyelmeztet, tiltakozik a kifejezetten inicializálatlanul maradt deklarációk miatt. A nevek világához, a névtérhez kapcsolódó probléma a helyettesítő (alias) nevek használata, illetve a névtúlterhelés (over-loading) kérdésköre. Az újranevezés, vagyis a helyettesítő nevek használatának engedélyezése több programnyelvben lehetséges. A lényege ennek az, hogy új nevet kötünk egy már létező, névvel is rendelkező entitáshoz. Alias nevet adunk neki. A 4.5. ábrán ADA nyelvi példákat mutatok be. Itt a korábban definiált I változó K néven is elérhető, illetve a korábban definiált A tömb középső elemére Kozepso néven is hivatkozhatunk. ADA K: Integer renames I; Kozepso: Integer renames A((N+M)/2); 4.5. ábra Újranevezés Egyes nyelvek az újranevezést nem minden entitásra engedik. Például típusnevekre kockázatos lehet az újranevezés, típusegyezőségi gondok léphetnek fel. A szigorúan vagy szigorúbban típusellenőrző nyelvek a típusnév újranevezést ezért nem engedik (pl. az ADA sem engedi). Az újranevezési lehetőség hozhat kényelmet a programozónak. Vannak azonban kockázatai, növeli a hibalehetőségeket. Személy szerint nehezen tudom eldönteni, vajon jó koncepció-e az aliasing. Ha úgy tetszik, az aliasing ellentéte a név túlterhelés: ugyanazt a nevet kapcsoljuk különböző entitásokhoz. Veszélye nem kíván sok magyarázatot, az entitásokra való hivatkozások összekeverése lehet eredmény. Teljes elkerülése szinte lehetetlen. Gondoljunk csak az operátorok túlterhelésére, ott az over-loading egészen természetes! Inkább az okozna gondot, ha külön egész összeadó és lebegőpontos összeadó + operátor lenne a nyelvekben! Az ADA nyelvben meglehetősen sok túlterhelés van, a C-ben is van, bár kevesebb, a C++ ismét növeli a túlterhelési lehetőségeket. Térjünk vissza a típusokhoz! Általában a hardver legalább is a mai hardverek három alap-típust támogatnak. Ezek az egész típusok, különböző bitszélességekben, a különböző méretű és pontosságú lebegőpontos típusokat, végül a karakteres, vagy szöveglánc típusokat. Éppen ezért ezek a típusok nyelvekben is létező, előre definiált alap-típusok. A nyelvekben persze további változatok is lehetnek. A C-ben pl. a karakter típus kifejezetten létezik, de az egy 8 bites szélességű előjeltelen egészként is viselkedhet, azaz egy rövid integrálisként. Vannak nyelvek, melyek kezelik a logikai (boolean) típust is, és ismét vannak, melyek a különböző típusú entitások címére mutató pointer típust is.

11 PROGRAMOZÁSI PARADIGMÁK 11 Miután a típus többek között értékhalmaz is, az üres halmaznak is megfelelhet típus! A C nyelvben ilyen típus a void típus! Nem minden nyelvben ismeretes hasonló típus! A nyelvek fejlesztői biztosítanak néhány különböző szélességű és pontosságú skalár alaptípust. Biztosítanak továbbá típus konstruktor mechanizmusokat, melyekkel a programozó új, akár összetett típusokat hozhat létre. A létrehozott új típusoknak akár nevet is adhat (ajánlott a hibalehetőségek csökkentése miatt, ebben is az olvashatóság könnyítése 2 miatt). A leggyakoribb típuskonstruálások a következők: Felsorolásos típus létrehozása (mikor is nem már meglévő típusból konstruálunk újat); Tömb típus készítése (beleértve az egy- vagy többdimenziós tömböket, a társtömböket); Lista típus előállítása (a funkcionális nyelvek egyik legfontosabb típusa ez, ott tárgyaljuk részletesebben, de az imperatív nyelvek is használhatják); Halmaz és batyu típus (ez sem az imperatív nyelvek jellemző típusa. A Modula 2 nyelv pl. ismeri.); Rekord, struktúra, vagy union típus. A programozó típus-definiálása során definiálni kell mind a reprezentációt, mind az operációkészletet. Az előbbiből adódik majd a helyfoglalási hossz és az értékkészlet, utóbbiból az operációkészlet. Az imperatív nyelvek fejlesztői mind a reprezentációk, mind az operáció-készlet definiálásához adni szoktak szabályokat, lehetőségeket és korlátokat, az objektum orientált programozásban azonban a programozó típus (osztály) definiálási lehetőségei kiszélesednek. Az új típusok definiálása után a definiált új típus ugyanazt a státust élvezheti, mind a régebbi típusok, legalább is a korlátlanul ortogonális nyelvek esetén. Az ortogonalitás általánosabban azt jelenti, hogy néhány fontos alapelvet betartva építkezünk, ezeket az alapelveket következetesen betartva. Kicsit pontosítva itt azt jelenti, hogy bármely típus-kostruktornál alkalmazhatunk bármely már korábban definiált típust, vagy másképpen: egy alapelv használatát a többi elv megléte vagy hiánya nem befolyásolja. A típusok világában kombinációs ortogonalitást jelent az, hogy akármilyen összetett deklarációban akármilyen ismert deklarációs mechanizmust használhatunk. A C-ben ez néha sérül (pl. union deklarációban inicializálás tilos), az ADA ebben jobb. A fajta ortogonalitás ha egy összetett típus tagja lehet alap típus, akkor akármilyen típus is lehet rendszerint biztosított a legfontosabb nyelvekben (C-ben is, ADA-ban is). A számbeli ortogonalitással ahol egy deklaráció használható, ott zéró vagy tetszőleges számú deklaráció is használható -- is lehetnek gondok, legalább is az, hogy a zéró változat különleges jelölést kívánhat. 2 Nem lehet hangsúlyozni, milyen fontos dolog a programok olvashatósága! Gondoljuk meg, egy forrásprogram részt mennyivel többször olvasunk, mint írunk!

12 12 PROGRAMOZÁSI PARADIGMÁK Az ortogonalitás tisztává teszi a nyelvet. Az egyszerű alapelvek követése feleslegessé tesz elkerülhető kérdéseket, segítheti a fordítóprogramok fejlesztőit. A ortogonalitás szép példáját mutatják a C nyelv összetett deklarációi, azok típuskonstruktorai, és a típus-kostruktorok valamint a nekik megfelelő operátorok viselkedési szabályai. Tanulmányozzák a C komplex deklarációs lehetőségeit [Darnell, Margolis, 1988]! Még mindig a típusok világánál maradva, szólhatunk a korlátozott típusokra való igényről. Hibalehetőségek elkerülését segíthetik a korlátozások. Egy egyszerű példán szeretném bemutatni a problémát. A hőmérsékletek Celsius fok mérőszámait tartalmazó változók típusának természetesnek tűnően megfelelnek valamilyen szélességű és pontosságú lebegőpontos típusok. Az értékkészletük elegendő (sőt, túl nagy is lehet). Az operációkészletükkel van azonban gond: hőmérsékletekkel kapcsolatban összeadások, különbségképzések, többszörözések, hányados képzések és összehasonlítások természetesen adódhatnak, hatványozásnak azonban nincs értelme. A lebegőpontos alaptípusokat viszont lehet hatványozni. Lehet, hogy erőltetett a példa, de érzékelteti, hogy néha szükség lehet korlátozott típusokra. Egyes nyelvek -- lehet, hogy közvetve -- biztosítanak korlátozott típusokat. Tömbindexeknek lehetnek pl. ilyenek. Volt már szó a típusegyezőségről a típusnevek újranevezése során. A kérdés úgy merül fel, hogy vajon mikor tekinthetünk két típust egyezőnek, esetleg hasonlítónak. Strukturális típusegyezőségről beszélünk, ha a két típus értékkészlete és operációkészlete megegyezik, és név egyezőségnek, ha a típusnevek egyeznek. Az utóbbi a szigorúbb egyezőség, és csakis névvel ellátott típusoknál van értelme. A strukturális egyezőség, nem egyezőség meglehetősen gyakori probléma, ui. összetett típusú változókat gyakran hozunk létre, anélkül, hogy az összetett típusnak kifejezetten nevet adnánk! A C nyelvben pl. névegyezőséget kívánnak bizonyos struktúra- és union operációk (értékadás), strukturális egyezőség kellhet csupán minden máshoz. Sőt, automatikus típus-átalakítás valósulhat meg a strukturális egyezőség hiányában bizonyos szituációkban. A típuskonverzió problémája akkor léphet fel, ha egy helyzetben valamilyen típust várunk, és ott mégis, más típusú adat van. Vajon történjen ekkor automatikus típus-átalakítás, vagy sem? Melyik a jobb megoldás? A C-ben az integrális típusok szélesítő konverziója egészen természetes. Az int-to-float átalakítás is természetes, fordítva azonban információvesztés lenne. A típus előrevetés kifejezett alkalmazása programozói fegyelmet kíván, némely esetben elkerülhetetlen. Az ADA ebben szigorúbb, erősen tipizált, erős típus-ellenőrzéses nyelv A programvezérlési szerkezetek kérdésköre Az imperatív paradigma szerint a programozó teljes kontrollja alatt van a végrehajtás menete. A programozó alapvetően három, bizonyos nézetek szerint négy vezérlési szerkezetet használhat a programvégrehajtás menetének szabályozására. Az alapvető szerkezetek a Soros végrehajtási szerkezetek (szekvenciális programszerkezet);

13 PROGRAMOZÁSI PARADIGMÁK 13 A különböző választási, elágazási szerkezetek; A különböző ismétlési szerkezetek, más neveken hurkok, ciklusok. Egy bizonyos felfogásban a végrehajtás menetét szabályozó szerkezetek a rutinhívások is. Kétségtelen, hogy a legegyszerűbb programszerkezetek a soros szerkezetek. Gyakoriak is. Egymás után végrehajtandó utasítások képezik ezeket a szerkezeteket. A soros végrehajtáshoz az egymás utáni utasításokat mutathatja egy sorszám (sequencer). Kifejezett sorszámok (explicite sequencer) lehetnek az utasításcímkék, mint amilyeneket egyes Basic nyelvjárások használnak. Kifejezett sorszámok nélküli nyelvek esetén az utasításokat utasítás határolók választják el, határolják, és egy utasítás végrehajtás után a határoló utáni, azaz a következő utasítás végrehajtása következik. Az utasítások lehetnek egyszerű vagy összetett utasítások. Utóbbiaknál az ismeretes az utasítás teste (body) fogalom. A legtöbb nyelvben a kombinációs ortogonalitás koncepciója miatt az összetett utasítás pontosan úgy kezelhető, mint az egyszerű. A modern nyelvek a fajta ortogonalitási követelménynek ha egy helyen lehet valamilyen utasítás, akkor ott akármilyen lehet megfelelnek. A számbeli ortogonalitási követelményt ahol lehet utasítás, ott akárhány lehet -- már nehezebb teljesíteni. Az egynél több előfordulás gondot okozhat egyes összetett utasítás testének meghatározásához, ezt a problémát összetett utasítás határolókkal (begin, end, vagy {, } szimbólumokkal) képzett utasítás blokk képzésével szokták megoldani. A nulla előfordulás lehetőségét ez is követelmény a számbeli ortogonalitáshoz az üres utasítás (void null statement) koncepcióval oldják meg. A szekvenciális szerkezetek mellett a választások, elágazások is alapvető programszerkezetek. Az elágazási lehetőségeket általában két összetett utasítással biztosítják a nyelvek: az if utasítással, illetve a switch vagy case utasítással. Az if két vezérlési fonál közötti választást biztosít egy feltétel teljesülésétől függően. A fajta ortogonalitás miatt persze a két ág további if-ekkel tovább is elágaztatható. Az egyes nyelvekben switch, másokban case utasítás egy kifejezés kiértékeléséből kapott pillanatnyi érték illeszkedésétől függően eleve több vezérlési fonál közül válasz egyet. Végül a ciklusok szervezésére is szüksége lévén a programozóknak, a programozási nyelvek tartalmaznak ciklus utasításokat. Lehet ismételni egy utasítást akár összetettet is -- előre kalkulált számszor (for). Rendszerint egy ún. ciklusváltozó számlálja a lefutásokat, minden futamban változtatva az értékét (akár újraszámolva az értékét, akár egy listából véve a soron következő elemet). De lehet ismételni egy utasítást amíg egy feltétel fennáll (while), vagy amíg az bekövetkezik (until). Ismerjük ezek elől tesztelő és hátul tesztelő változatait. Az összetett ciklus utasítás teste lehet utasítás blokk. Ebben szerepelhet a break és a continue utasítás is. A break kiugrik a ciklusból, és a ciklus utasítás utáni utasításra adja a vezérlést. A continue pedig megszakítja a blokk végrehajtását és azonnal a következő ciklusmenet végrehajtására tér (a ciklusszámláló igazí-

14 14 PROGRAMOZÁSI PARADIGMÁK tásával és elől tesztelő ciklusnál a teszteléssel persze). A break és continue utasításokat szemben a goto utasítással, a szakemberek nem kárhoztatják. A rutinhívások kérdéskörét egyesek akik az imperatív paradigma elveiből a vezérlés menetének lépésenkénti meghatározását tartják fontosabbnak -- szintén a programvezérlés menetének befolyásolására való szerkezetnek tekintik. Kétségtelen igazolható ez a felfogás, hiszen a rutinhívás helyéről a programvezérlés menete ugrik a rutin belépési pontjára (természetesen az argumentumátadás megtörténik, de e felfogás támogatóinak nem ez a fontos), majd a rutinból visszatérve a vezérlés a hívás utáni utasítással folytatódik (s függvények visszatérési értéket is adnak vissza, ami e felfogás szerint nem lényeges). Mindazon nyelvek, melyekben eljárás (procedure) típusú rutinozási lehetőség van, többé-kevésbé követik ezt a felfogást. Más nyelvek fejlesztői csakis a függvény típusú rutinokat engedik. A függvénynek mindig van visszatérési értéke, ami megjelenik ott, ahol a függvényhívás történik, és ezzel egy kifejezés operandusa lehet. Felfogásbeli különbség ugyanabban a paradigmában: ha az adatokon és típusokon van a nagyobb hangsúly, akkor a rutinok használata értékkiszámítás, azaz kifejezés, ha viszont a lépésenkénti végrehajtás a hangsúlyos, akkor a rutinozás a vezérlés menetének egyik meghatározási módja. A Neumann típusú gépek hiba- és esemény-kezelése jellegzetes. Miután az imperatív nyelvek nagyon illenek a Neumann gépekhez, ezek eseménykezelése tükrözi a gép hibakezelését. Esemény bekövetkezése a Neumann gép számára jelződik. A jelzés hatására gépi instrukció-folyam végrehajtása megszakad (interrupt), a gép állapota lementődik, majd a vezérlés az esemény kezelőjére (handler) ugrik. Ha a kezelő instrukciófolyamból van visszatérés, a gép állapotot visszaállítják, és folytatódik a normál instrukciófolyam futása. Az eseménykezelést programozási nyelvek támogathatják, bizonyos feltételek bekövetkezéshez (on condition) kezelő rutinokat (handler) rendelve. A program futásában az esemény bekövetkezése váratlan, és sok esemény aszinkron, abban a tekintetben, hogy nem lehet utasításokhoz kötni a bekövetkezését. Az aszinkron jelleg miatt elágazó utasításokkal nem lehet a feltétel bekövetkeztét ellenőrizni. A korszerű eseményvezérelt (event driven) programozáshoz a nyelvi fejlesztők szoktak on condition mechanizmusokat biztosítani Állapotátmenetek az imperatív programokban Az imperatív programok változóinak pillanatnyi értékei adják a program futási állapotát. (Az állapottér elemeihez tartoznak persze a processzor regiszterei, az I/O eszközök pufferei és regiszterei is.) Egy-egy értékadás változtatás ezen az állapottéren. Az előbbiekben már ismertetett felfogásbeli különbség az adatok vagy a lépésenkénti végrehajtás a hangsúlyosabb -- megjelenhet az értékadással, ezzel az állapotváltoztatással kapcsolatban is. Azon nyelvekben, ahol a fejlesztők a vezérlés mentének megszabását tartják fontosabbnak, van értékadó utasítás. Az értékadó utasítás jobboldalán kiértékelendő kifejezés szerepel, a kifejezés az utasításnak része. Jellemzően ilyen nyelv a Pascal

15 PROGRAMOZÁSI PARADIGMÁK 15 vagy az ADA. Az adatokra é s típusaikra koncentráló fejlesztők nyelveiben a kifejezések állnak előtérben. Minden program elem tulajdonképpen kiértékelendő kifejezés, emlékszünk, a függvények is arra valók, hogy egy értéket adjanak. Nincs kifejezett értékadó utasítás e felfogás szerint, hanem értékadó kifejezés van, mint a C nyelvben. És miután a nyelv szabályai szerint az utasításhatároló szimbólum elhelyezése egy kifejezés után kifejezés utasítássá teszi azt a kifejezést, az értékadó kifejezés mellékhatásaként (side effect) történik az értékadás. Az imperatív programoknak meglehetősen nagy állapottere van, a program futása tekinthető az állapotátmenetek láncolatának Az imperatív programok számítási modellje Adott programozási paradigmának megfelelő programozási nyelvek számítási modelljei ugyanazok. A számítási modell összetevőit [Sima et al, 1998] szerint a számítások alapelemei, a problémaleíró modell és a végrehajtás modellje képezik. A problémaleírás modelljét a leírás jellege és módszere határozza meg. A végrehajtás modelljét a végrehajtási szemantika és a végrehajtás kontrollja adja. Az imperatív nyelvekben a számítások alapelemei az azonosítható entitásokhoz rendelt típusos adatok, a literálok és változók. A problémaleírás imperatív jellegű, utasítási lépéseket megadó. Egy felfogásban procedurálisnak is jellemzik a problémaleírást, ekkor kompozíciósdekompozícós problémadefiníció hangsúlyozódik. A végrehajtási modell egyik összetevője (a végrehajtási szemantika) állapot átmeneti szemantika, a másik összetevő (végrehajtási kontroll) közvetlen kontroll A FUNKCIONÁLIS PROGRAMOZÁS PARADIGMÁJA Az imperatív nyelvek segítik a programozót, hogy algoritmusokat rögzítsen, amik pontosan megadják, milyen lépésekben oldjuk meg a problémát. A hozzátartozó számítógépi modell állapotokat kezel a változókon át, ahol is az állapotok a gép memória tartalmának változatai. Az imperatív paradigma és a Neumann gép jól megfelel egymásnak, és hatékony megvalósítást biztosítanak. A hatékonyság mellet azonban a paradigma néha korlátoz: vannak problémák, melyek nem illenek a Neumann modellhez, az imperatív programozással viszont a problémát a gépi modellhez akarjuk illeszteni. Ez kötöttség, jó lenne néha ettől megszabadulni. Egyes problémák esetén azzal foglalkoznánk, hogy mit kell kiszámítani, ahelyett, hogy azt keresnénk, hogyan, milyen lépésekben, hogyan kell kiszámítani az eredményt A paradigma A funkcionális program a nyelvhez előre definiált és a programozó által definiált függvények hívásából áll.

16 16 PROGRAMOZÁSI PARADIGMÁK A függvények kifejezéseket értékelnek ki. Egy függvény mint a matematikában egy értéktartományból képez le egy másik értéktartományba. A függvény ugyanazokkal az argumentumokkal ugyanazt az eredményt adja, nincsenek hát állapotok és mellékhatások, csakis értékkiszámítás van. Nem számít, hogy mikor hívjuk a függvényt, csak az, hogy melyiket hívjuk. Nincs tehát értékadás, hanem csak érték kiszámítás. A funkcionális programban a függvényeket természetesen definiálni kell. A program tehát függvénydefiníciók és függvényhívások sorozata. Természetesen, a funkcionális programok is használnak adatokat. Ezek tulajdonképpen típusos értékek és ezek listái (ismerünk típus nélküli adatokat kezelő nyelvet is). Név szerint két ismert funkcionális nyelvet említek meg. Egyik nyelv a Miranda 3. Ez tiszta funkcionális nyelv. A másik, a LISP 4. A LISP a legrégebbi funkcionális nyelv, valójában nem tisztán funkcionális jellegű, mert van benne értékadás és ezzel nem teljesen állapotmentes A funkciók A nyelv alapvető építőkövei a funkciók. Minden függvénynek van neve és zéró vagy több argumentuma. Egy függvény kiszámít egy értéket ami lehet összetett, állhat több elemből pusztán az argumentumaitól függően. Azaz ugyanazzal az argumentumokkal a függvény mindig ugyanazt az értéket szolgáltatja. A függvény argumentumai értékek lehetnek összetettek --, amiket névvel ellátott, vagy névnélküli adatok, kifejezések, vagy éppen függvények biztosítanak. A rekurzió abszolút természetes a funkcionális nyelvekben, ismétlések és ciklusok helyett éppen a rekurziót használhatjuk. Nézzünk egy egyszerű példákat mind a Miranda, mind a LISP nyelvben (4.6. ábra). Figyeljünk fel arra, hogy a feltételes kifejezésekkel definiált érték-kiszámítás (a faktoriális függvény definíciókban látunk ezekre példát) egymás után írt programszerkezetei nem egymás után végrehajtható lépéseket jelentenek, bár a sorrendjük természetesen nem cserélhető fel! 3 Részletesebben lásd: [Clack et al, 1994] 4 Lásd [Zimányi et al, 1989]

17 PROGRAMOZÁSI PARADIGMÁK 17 Miranda celsius:: num -> num celsius f = (f-32) * 5/9 celsius 68 => 68 // típus deklaráció // definíció // hivatkozás LISP (defun celsius (f) (* (- f 32.0) (/ ))) (celsius 68.0) => 68.0 Faktoriális, Miranda fac:: num -> num // típus deklaráció fac x = 1, if x = 0 fac x = x * fac (x 1), othervise //definíció fac 3 => 6 // hívása Faktoriális LISP (defun fac (x) (if (= x 1) 1 (* x (fac (- x 1))) )) // definíció (fac 3) => 6 // hívása 4.6. ábra Egyszerű mintaprogramok Adatszerkezetek A funkcionális nyelvek alapvető összetett adatszerkezetei a listák. A lista szerkezet zéró vagy több elemből áll. Az elem lehet -- típusos nyelvnél típusos, nem tipizáló nyelvnél típus nélküli érték, vagy lista is. A zéró elemből álló lista az üres lista. A lista adatszerkezetben a lista feje (head) a lista első eleme. A lista feje skalár érték, ha a lista első elem maga skalár, viszont lista, ha az lista. A lista farka (tail) is definiálható: a lista fejé nélküli maradék lista a lista farka. A lista farka mindenképpen lista. Érezzük a rekurzió koncepciót a lista fogalomban, annak definíciójában. Igen, a lista rekurzíven definiálható: A lista vagy üres lista, vagy fejből és farokból áll. A lista feje vagy érték, vagy maga is lista. A fej az első eleme a listának. A lista farka mindig lista, a fej nélküli maradéka a listának. A 4.7. ábrán néhány példát mutatunk be lista szerkezetekre.

18 18 PROGRAMOZÁSI PARADIGMÁK Miranda listák [1, 4, 9, 6] // 4 egész listája [1.. 10] // 10 egész listája [ a, b, c ] // 3 karakter listája [ ] // az üres lista [[2, 4, 6], [1, 3, 5, 7, 9]] // 2 listából álló lista LISP listák ( ) // 4 egész listája ("a" "b" "c") // 3 karakter listája ( ) // az üres lista nil // az üres lista 4.7.ábra Példák listákra Beépített függvények Néhány fontos beépített függvényt megemlítünk, először a Miranda nyelvi nevét, majd a LISP nevet, törtvonallal elválasztva: A lista fejét előállító függvény a hd/car. A lista farkát a tl/cdr adja. Beszúrás a lista elejére a :/CONS függvénnyel történhet. Listákat összefűz (concatenate) a ++/APPEND operátor, illetve függvény. Elemekből listát képez a pair/list függvény. Egy lista hosszát adja vissza a #/length függvény. Az aritmetikai operációk a Mirandában akár függvénnyel akár operátorokkal összekötött kifejezéssel megadhatók, míg a LISP függvényeket alkalmaz itt is. Viszont az aritmetikai függvények neve lehet a mi általunk szokásosa operátorként használt karakter. A 4.8. ábrán egyszerű példákat mutatunk be beépített függvényhívásokról, operátor használatról Miranda nyelven. A funkcionális nyelvek használják a magasabb rendű függvények koncepcióját. A magasabb rendű függvény egy argumentuma maga függvény. A magasabb rendű függvény argumentuma nemcsak egyszerűen értéket szolgáltat, hanem ezt az argumentum függvényt használjuk a többi argumentumra. Egy tipikus példa a map magasabb rendű függvény, melynek első argumentuma egy függvény, másik argumentuma lista, maga a függvény pedig listát eredményez. Az első argumentumot alkalmazza minden listaelemre, így állítja elő az eredmény listát. Másik tipikus magasabb rendű függvény a foldr (fold right, göngyöld jobbra)

19 PROGRAMOZÁSI PARADIGMÁK 19 függvény. A 4.9. ábrán mintákat mutatunk be a map és foldr függvények használatára. Miranda hd [10, 20, 30] => 10 tl [10, 20, 30] => [ 20, 30] 5 : [ ] => [5] // beszúrás 3 : [5, 4, 6] => [3, 4, 5, 6] //beszúrás A beszúrás típus-deklarációja: : :: (α, [α]) -> [α] // ahol α bármilyen típus A hossz-visszaadás # függvénye kb. így lehet definiálva: # :: [α] -> num // típus-deklaráció # x = 0, if x = [ ] # x = 1 + # (tl x), otherwise // definíció # [3.. 5] => 5 // hívása A lista összefűzésre van ugyan operátor, mi egy függvényt definiálunk erre példaként: concat :: [α] [α] -> [α] concat x y = y, if x = [ ] concat x y = (hd x) : concat (tl x), otherwise 4.8.ábra Miranda példák A kiértékelési sorrendről Előzőleg, a függvénydefiníciókban használatos feltételes kifejezések említésekor mondtuk, hogy bár programsorok sorrendje nem cserélhető fel tetszőlegesen, az egymásutániság nem jelenti az egymás utáni számítási lépések definícióját. Nem jelenti azt, hogy tedd előbb ezt, utána ezt, mint az imperatív nyelvi utasítások. A kiértékelési sorrend mégis érdekes lehet. Már az imperatív nyelvek operátorainak precedencia- és asszociativitási (tapadási) szabályai felvetik ezt a problémát, és ha megjegyezzük, hogy ez nem az imperatív nyelvek programvezérlési menetet meghatározó sorrendiségi probléma, akkor megérthetjük és elfogadhatjuk, hogy a funkcionális paradigmában is jelentkezik ez a probléma. A feltételes kifejezések elemzésével eljuthatunk arra a következtetésre, hogy nyilvánvalóan előbb a feltétel értékelődik ki, és utána a feltételnek megfelelő kifejezés. Mi a helyzet azonban függvények argumentumaival? Azok mind kiértékelődnek? Milyen sorrendben?

20 20 PROGRAMOZÁSI PARADIGMÁK Miranda map func lista // a map hívási szintaxisa Legyen egy triple (háromszorozó) függvényünk triple :: num -> num triple x = x * 3 és ekkor map triple [1,2,3, 4] => [3, 6, 9, 12] Párok elemeinek összegéből álló lista az eredmény map (+) [[1, 2], [3, 4]] => [3, 7] A foldr hívási szintaxisa foldr func x lista és ekkor foldr (+) 0 [2, 4, 6] => (2+(4+(6+0))) => 12 // sum foldr (*) 1 [2, 4, 6] => 48 // produktum foldr (&) true lista // logikai és minden listaelemre 4.9 ábra Magasabb rendű függvényekre példa Egyes függvények minden argumentuma kiértékelődik. Ezek az eval típusú 5 függvények. Mohó kiértékelésnek (eager evaluation) nevezzük ezt az esetet. Vannak függvények, melyeknek nem minden algoritmusuk értékelődik ki, ezek a nem eval típusúak. Az argumentumok kiértékelési sorrendje kétféle lehet. Egyik sorrend az ún. applikatív sorrend (applicative order), mikor is a legbelsőbb kiértékelendőből kiindulva történik a kiértékelés. A mások sorrend neve a normál sorrend (normal order). Ekkor a legkülsőbb kiértékelendőket kezelik először. Miranda cond :: bool α α -> α cond b x y = x, if b cond b x y = y, otherwise // applikatív renddel fact1 :: num -> num fact1 n = cond (n = 0) 1 (n * fact1 (n 1)) cond felt a b // (1) hívás fact1 3 => error // (2) hívás ábra Gondok az applikatív kiértékelési rendnél Matematikai képzettségünk miatt is, az applikatív sorrend tűnhet természetesebbnek. Nos, a mohó kiértékeléshez az applikatív sorrend tartozik, míg a halasztott kiértékeléshez (lazy evaulation) a normál sorrend. 5 Az angol evaluate szó rövidítéséből.