Végülis igazad van. Tulajdonképpen épp emiatt is álltam neki hogy megcsinálom az infix modult is beléje nekije, a Drágaszágnak... hozzáteszem azért, eredetileg nem akartam. De aztán rájöttem, miért is ne, hiszen a Peri legnagyobb előnye ÉPP AZ, hogy tulajdonképpen nem számít mennyire lassú (és még csak nem is lassú, simán ráver épp kb 20 százalékot a JIT nélküli Pythonra, néha sokkal többet is...), ugyanis direkt úgy van megírva hogy talán épp ez az a szkriptnyelv ami a legmesszebbmenőkig támogatja a bővíthetőséget külső C/C++ nyelven írt libekkel! Ez a peri egyik legislegnagyopbb előnye!
Vagyis ha valahol van egy „bottleneck” a sebességben, egy szűk keresztmetszet, azt egyszerűen meg kell írni C-ben, besúvasztani egy külső libbe, és kész, a többit lehet nyugodtan Periben írni tovább...
Akkor meg tényleg, lehet akár infix is. És különben se kötelező az infix jelölésrendszer, pláne hisz írtam, még vegyesen is használható...
A bosszúságom az, egy ilyen infixes modullal temérdek babramunka van. Gyakorlatilag külön meg kello írnom újra az egész nyelvet (legalábbis a 80 százalékát), külön kezelgetve az egyes típusok esetét (és a Peri egyelőre 13 típust támogat built-in...), szóval irtó pepecselős. Nem a kifejezéskiértékelés algoritmusának leprogramozása a nehéz, azt csak a pelenkás kezdők hiszik. Ott egyszerűen tisztában kell lenni vele mit jelent az a fogalom hogy „rekurzió”, aztán kész ennyi, programozástechnikailag nem egy nagy durranás. De minden operátort le kell programozni, minden típusra külön, plusz figelembe venni az egyes specialitásokat mint például amikor a változókat postfix operátorokkal módosítjuk hogy teszemazt
variable++
és hasonlók. Rém macerás na. Lassan megy, mert mindent alaposan át kell nézni, és rengeteg unit-tesztet írni.
Egyelőre a következő típusokkal vagyok meg:
unsigned long long
signed long long
double
De mondom, van még tíz... És a stringtípustól már előre rettegek mert az a legkomplexebb. Ja és ezen említett három sincs kész azért teljesen, mert az még egyikben sincs benne, mit kezd akkor ha egy stringkonstans jön közbe a kifejezéskiértékelés közepén nekije. Nem tudom ugyanis eldönteni, ilyenkor mit csináljon mondjuk az unsigned long long típus kiértékelője. A lehetséges megközelítések:
1. A stringkonstans pointere legyen a stringkonstans „értéke” ezesetben, egész számként. Ez logikusan illene is a nyelvem eddigi filozófiájához, mert sehol nincs nálam megkülönböztetve egymástól a pointer és az egész szám.
2. Próbálja castolni a stringkonstans tartalmát előjel nélküli egész számra. A maga módján ez is logikus, csak életszerűtlen - ki az a hülye aki egy egész számokkal műveletet végző kifejezésbe egy számot stringként ír bele?! Aztán meg mi van ha a stringkonstans nem értelmezhető egész számként - ekkor jelezzen hibát, vagy tekintse az értékét nullának, vagy...?
3. Semmit se csinál vele, úgy tekinti itt vége van az aritmetikai kifejezésnek, a stringkonstans már nem tartozik hozzá. Jelen pillanatban ez a szitu.
Hasonló problémákba ütközöm majd, előre látom, a stringkifejezések kiértékelőjénél. Mi van ha egy ilyen kiértékelő egy egész számba ütközik bele? Számkonstansba mondjuk? Tekintse úgy, hogy az már nem része a kifejezésnek? Vagy castolja stringgé? Ha igen, milyen hosszú stringláccá, és legyen-e benne előjel az elején? Stb.
Szóval a számomra RÉG nem az a gond, meg tudok-e írni egy programnyelvet, hanem döntenem kell a nyelv „milyenségéről”, ami a maga módján persze jó szórakozás, de ugyanakkor gyakran cseppet se egyértelmű, melyik döntéssel járok jobban. Mármint, melyik döntéssel lesz jobb a nyelv végül.