A számítógépes program és az emberi gondolkodás
Már a harmadik részéhez értem annak a sorozatnak, amiben a programozási nyelvek jelentéstanának egy furcsa oldaláról beszélek. A számítógép és az ember kapcsolatáról mindig úgy szoktunk beszélni, hogy hogyan lehet számítógéppel utánozni azt, ahogy az ember viselkedik (beszél, megért és így tovább). Itt viszont arról volt szó, hogy a számítógépes programoknak mi az a vonása, ami az emberi nyelvekkel összehasonlítva annyira megnehezíti a használatukat.
Eddig arról beszéltem, hogy a programok minden futásuk alkalmával ugyanazt „csinálnák”, ha nem lennének paramétereik, változó részeik, amik akár minden egyes futásnál más értéket vesznek fel, és emiatt viselkednek a programok eltérően egyik esetről a másikra. Vagyis nem egészen pontosan írnak le egy folyamatot, hanem csak nagyjából, vázlatosan; a változó részeik folyamatról folyamatra mások lehetnek, attól függően, hogy milyen paramétereket állítunk be, milyen értékeket rendelünk a paraméterekhez.
Azt is elmondtam, hogy kétféle lehetőség létezik a paraméterek megadásánál. Az egyik az, hogy van egy meghatározott sorrend, amiben a paramétereket megadhatjuk, és innen „tudja” a program, hogy melyik paraméternek mi az értéke. Például „helyettesítsd
A probléma mindkét esetben az önkényesség. Semmiből sem következik (és ezért nagyon nehezen megtanulható), hogy miért éppen az a paraméterek kötelező sorrendje, ami, és ugyanígy semmiből sem következik, hogy épp azokkal a kulcsszavakkal lehet megadni az értéküket, amikkel. Ezek mind a programozó döntései, és aki fel akarja használni a programot, az csak a dokumentációból tudhatja meg, hogyan kell a paramétereket megadni.
Végül azt is elmondtam, hogy van persze önkényesség a természetes nyelvekben is bőven, még abban is, hogy milyen esetraggal vagy névutóval jelöljük egy esemény különböző résztvevőinek szerepét (például hiányzik
A programozási nyelvekben semmi ilyesmire nincs semmiféle biztosíték. Úgy fogalmazhatnánk, hogy minden programnak teljes mértékben a „belügye”, hogy hogyan kezeli a kívülről megadott paramétereket (akár a sorrendjük, akár a kulcsszavaik szempontjából). Akár a sorszámukkal, akár kulcsszavakkal azonosítjuk a paramétereket, az olyan, mintha elneveznénk őket, és a külvilágnak ismernie kellene a nevüket ahhoz, hogy rögzítse az értéküket. Márpedig a nevek afféle címkék, teljesen önkényesek, puszta névadásból fakadnak, semmilyen módon nem utalnak arra, hogy mit jelölünk velük. Itt kell tehát felvennem a fonalat.
Kényszerek helyett
Azt már az előző részben is említettem, hogy természetesen szóba se jöhet olyan megoldás, ami a programozók megregulázását feltételezi, vagyis hogy a megszokott szokásaikkal szemben másféle szokásokra kötelezzük őket. Csak egyetlen megoldás jöhet számításba, hogy az egyes programoknak ne legyen a belügyük, hogy hogyan bánnak a paramétereikkel.
Közelebbről pedig csak olyan megoldásra gondolhatunk, ami az elnevezés önkényes aktusának a helyébe valami mást állít. Hogyan tudunk azonosítani valamit, ha nem az elnevezésével? Próbáljuk csak ki, hogy mit tehetünk, ha nem ismerjük valaminek a nevét. Nyilván „körülírással” fogunk próbálkozni.
A természetes nyelvekben tulajdonképpen valami ilyesmi történik. Például igaz, hogy a -val/-vel toldalékot sokféle célra használjuk a magyarban, de ha külön nézzük egy-egy használatát, akkor egyfajta körülírással jellemezhetjük a szerepét. Amikor az eszközhatározót jelöli, akkor olyasmi leírást helyettesít, hogy 'ezt a dolgot eszközként használva', amikor meg társhatározót, akkor olyat, hogy 'ezzel a dologgal együtt'. Az már persze az állítmány és a bővítmény jelentésén múlik, hogy pontosan hogyan valósulhat meg ezeknek a körülírásoknak a tartalma. Például az autóval megy kifejezés megértésekor ki kell számolnunk, hogy hogyan lehet az autót a mozgás eszközeként használni (valószínűleg úgy, hogy beleülünk), illetve hogy milyen lehet a mozgás, amikor autóval mint eszközzel történik. A Józsival mentem kifejezés megértésekor nem sok számolásra van szükség: Józsi és én egyidejűleg mentünk valahova, ráadásul egymás közelségében.
A természetes nyelvre annyira jellemző többértelműséget a számítógépes programozási nyelvek szeretik elkerülni (bár nem mindenben). Ezért azzal nem kell most foglalkoznunk, hogy a fenti példákban a -val/-vel többértelműsége miatt még azt is ki kell találni, hogy az autó esetében eszközről, Józsi esetében pedig együttességről van szó. Most attól is eltekinthetünk, hogy tulajdonképpen maga a megy ige is többértelmű, legalábbis abban az értelemben, hogy egészen másképpen kell egy eszköz segítségével helyet változtatni, mint a saját lábunkon. Ilyen eltérések azonban a programok esetében is lehetnek, vagyis lehet olyan, hogy egy program eltérően működik attól függően, hogy valamelyik paraméterének mi az értéke.
A természetes nyelvvel való párhuzam lényege annyi, hogy az értelmes, nem önkényes paraméterezés azon alapul, hogy ismerjük az állítmány vagy a program tartalmát, így tartalmilag, nem pedig önkényes formai eszközökkel kapcsoljuk hozzá a paramétert. Mondok egy példát a számítógépes programokból. Egy csomó olyan program van, ami fájlokat alakít át. Az átalakítás természetétől függetlenül ezek a programok megnyitnak egy fájlt, a tartalmával dolgoznak, a számításaik eredményeit pedig egy másik fájlba írják ki. Ha ennyit tudunk egy program szemantikájáról (és ez nyilván nem a belügye a programnak), akkor ennek elégnek kellene lennie, hogy a megfelelő paramétereket (az elolvasott és a kiírt fájl nevét) standard módon adhassuk meg. Az lenne a kívánatos, ha az ilyen programok egész családjában minden családtaghoz pontosan ugyanolyan módon kellene megadni a paramétereket.
Hogy formailag ez hogyan valósulna meg, az mellékes kérdés, például kulcsszó-szerűségeket is lehetne használni (pl. pdf2svg from f1 to f2 jelölhetné, hogy az f1 fájlt akarjuk átalakítani, és f2 lesz az átalakított fájl neve). A lényeg csak az, hogy ha például ezt a megoldást választjuk, akkor a from és a to ne kulcsszavak legyenek, hanem tartalommal rendelkező kifejezések, amelyeknek olyan programok esetében, amik nem fájlt olvasnak be, illetve írnak ki, értelmetlenséghez vezetnek (és ezt szép tartalmas hibaüzenettel is lehet jelezni). A from f1 és a to f2 tartalma pedig egy-egy körülírás (a nyelvészetben ezeket határozott leírásnak nevezik), ami tulajdonképpen arra a programrészletre utal, ami az egyik fájl beolvasását, illetve a másik kiírását tartalmazza.
Még közelebb az emberi nyelvhez
Két irányban lehetne még továbbfejleszteni ezt a „tartalmas” paraméterezést. Az egyik az lenne, hogy – a természetes nyelvek mintájára – akár a többértelműséget is meg lehetne engedni, ha az nem vezethet félreértéshez. Például elképzelhető, hogy a from és a to akár virtuális helyeket is jelölhet (például foldereket, ahonnan és ahova egy fájlt át akarunk helyezni). Vagy például azt is meg lehet tenni, hogy legyen olyan paraméter (nevezzük „tárgynak”), aminek nincs saját jelölése, és ez mindig az a paraméter, ami a legfontosabb szerepet játssza a program által leírt folyamatokban. Vagyis itt már sokszoros többértelműség lenne, ahogy a tárgy a természetes nyelvekben is ilyen szokott lenni. (Az „alany” jelölése a programok esetében általában értelmetlen, hiszen a programokat mindig „felszólító módban” használjuk.)
A továbbfejlesztés másik iránya egy kicsit már a science fiction kategóriájába esik. Ez az lehetne, hogy a paraméterek és a program közötti viszony metonimikus is lehessen. Például a természetes nyelvben minden további nélkül megértünk olyan kifejezéseket, mint hallom a Szigetet, holott hallani szigorúan véve csak hangot lehet, a Sziget pedig nem hang. Nyilvánvaló, hogy a megértés folyamatában, ha mindenáron egy folyamatot akarunk feltételezni, az zajlik le, hogy a Sziget szót ilyenkor metonimikusan értjük, mint 'az, ami a Szigethez kapcsolódik, és hallható', és így jutunk el oda, hogy a Szigeten szóló zene (vagy más onnan jövő zaj). Hasonló ez ahhoz az esethez, amikor zöld almáról beszélünk: a metonímia ilyenkor is egy közbülső jelentéselem beillesztését feltételezi. Ami az almán zöld szokott lenni, az nem a belseje, hanem a héja, tehát a zöld alma értelmezése 'zöldhéjú alma'.
Hogy nézne ez ki programok esetében? Arról beszéltem, hogy a paraméterek megadásánál meg kellene követelni, hogy értelmes szerepük legyen a paraméternek, és ennek a szerepnek olyannak kell lennie, amit a programról való tudásunk alapján egyértelműen meg lehet feleltetni a program egy részletének. (Így például a fenti példában, a fájl-átalakító programok esetében ez a tudás az, hogy a program egyik részlete egy fájlt olvas be, egy másik részlete pedig egy fájlt ír ki.) A metonímia pedig azt jelentené, hogy ebben a megfeleltetésben megengedett egy közvetítő jelentés-elem feltételezése. Miért is ne?
Azt hiszem, a metonímia szimulálása is megoldható, csak az kell hozzá, hogy még többet tudjunk a program tartalmáról. Vegyünk egy példát. Tegyük fel, hogy van egy paraméterünk, aminek a „jelentése” az, hogy egy hangerő-értéket ad meg, de a programunkról közvetlenül nincs olyan tudásunk, hogy hangot ad ki. Mondjuk egy videólejátszó programról van szó, aminek egy része persze természetesen gondoskodik a hang lejátszásáról, de ez valahol a programon belül egy másik program elindításával történik. Tehát ahhoz, hogy a hangerő-paramétert megfelelően értelmezni tudjuk, nemcsak magát a programot, hanem a benne felhasznált, szubrutinként elindított többi programot is ismernünk kell. Vagyis a metonímia nem más, mint ilyen közvetett paraméter-megadás.
Mi is a cél?
Mindeddig arról írtam, hogy könnyebb lenne megtanulni a programok használatát, ha egységes, tartalmi alapú lenne a paraméterek használata. Könnyen lehet, hogy a programozók ezt meglehetősen lényegtelen részletnek tartják, különösen, mivel elég nagy árat kellene érte fizetni: a programok tartalmáról részletes adatbázist kellene fenntartani és karbantartani (bár ez szerintem nagy mértékben automatizálható lenne). Én tehát egy egyszerű didaktikai szempontból indultam ki. Ugyanakkor a természetes nyelvekkel való párhuzamok arra utalnak, hogy az emberi nyelvek jelentéstanának a jobb megértéséhez is hasznosak lehetnének ezek a tapasztalatok. Lehet, hogy a mesterséges nyelvekkel, például programozási nyelvekkel való kísérletezés közelebb vinne a bővítmények, a módosítók, az igék és mások jelentéstanának, a metonímiának és a metaforának a megértéséhez.
A szerző nyelvész, az MTA Nyelvtudományi Intézetének főmunkatársa. A Qubit.hu-n megjelent összes írása itt olvasható.
Kapcsolódó cikkek a Qubiten: