( uid_21365 | 2020. 12. 07., h – 05:02 )

Szerkesztve: 2020. 12. 07., h – 05:04

Na, csak megcsináltam ma a strintípusra is a kiértékelőt... Bár természetesen lehet hogy bővül majd még ezzel-azzal, de legalább az értékadás megvan, és lehet stringeket összeadni is. Ritkán van más egy stringkifejezésben, mint összeadás, azaz konkatenálás. Ezzel szemben az én kiértékelőm stringet szorozni is tud számmal, ami természetesen multiplikációt jelent, és ki is tud belőle vonni számot, ami azt jelenti hogy ennyivel csökkenti a hosszát, lehagyva valahány karaktert jobb oldalról.

Íme egy kis példaprogram (semmi értelmeset nem művel de unit tesztnek jó):

 

###sysinclude standard.uh
###sysinclude infix.uh
#s
100 mem sto ss
100 mem sto mystr
mystr === "abcdef" @mystr printnl
ss    === "12345"  @ss    printnl
mystr += "CENTRE" + @ss @mystr printnl
mystr -= 4 + 2 @mystr printnl
mystr += ( ss * 2 ) + "*" @mystr printnl
mystr *= 3 @mystr printnl

@mystr inv mem
@ss    inv mem
end
{ „mystr” }
{ „ss” }

Outputja:

abcdef
12345
abcdefCENTRE12345
abcdefCENTR
abcdefCENTR1234512345*
abcdefCENTR1234512345*abcdefCENTR1234512345*abcdefCENTR1234512345*

Látható, még a zárójeleket is tudja kezelni a kifejezésen belül. (Naná! Rekurzió rulez!)

Egyedül a === operátor szorul magyarázatra. Nos ez a közönséges = operátornak felel meg, AKKOR, ha infix módon van értelmezve. Hm, ez így lehet hogy zavarosan hangzik... Szóval, attól hogy az infix.uh fájlt beinclude-oljuk, még SEHOL SEM változik meg a Peri szokásos szintaktikája! Ami ugye RPN típusú. Egyszerűen a periben általában nincs használva a +=, -=, *=, /= és más hasonló operátorok, mert minek, RPN nyelvben tulajdonképpen nincs olyan hogy „balérték”. Jó, rá lehet fogni nyakatekerten erre-arra, de tulajdonképpen minden a stackon keresztül értelmeződik.

E += stb mnemonikokat tehát nyugodtan felruházhattam infix jelentéssel. Ha az infix.uh fájl be lett includeolva, akkor e mnemonikokat infix operátoroknak tekinti a nyelvem, s ettől kezdve mindaddig amíg az utána következő mnemonikokat értelmezni tudja az infix notation szabályai szerint, azokat annak megfelelően is kezeli.

Az = jelnél azonban bajba kerültem, mert azt az RPN szintaxisban is használom. És nem akartam lemondani arról, hogy a két fajta notationt vegyesen is lehessen használni. Így egyszerűen kitaláltam az === mnemonikot, ami nem más mint egy "infix =" operátor. Mint látható a fenti példaprogramból, ez az egyetlen extravagáns jelölés tulajdonképpen az infix notation esetén, minden más teljesen megszokott.

Az is látható amúgy, nem szükséges kitenni a kifejezések végére a pontosvesszőt (vagy bármi annak megfelelő jelet). A Peri okos, tudja hol van vége egy kifejezésnek: természetesen mindig ott, ahol már valami olyasmi jön ami nem tartozik a kifejezéshez, azért, mert nem értelmezhető a kifejezés addig végrehajtott részével kontextusban. De ettől még amúgy létezik a nyelvemben a pontosvessző, aki akarja kiteheti bárhova, semmi gond: ekkor üres utasításként funkcionál. Szóval aki akarja, javíthatja vele a kód olvashatóságát, csak nincs megkövetelve a használata.

Szerintem így már kezd egész olvasható lenni a Peri. De ha valakinek más erről a véleménye, csak szóljon nyugodtan! (úgyis eleresztem a fülem mellett... virtuális vállveregetésre, „buksisimogatásra” vágyom hogy itt valamelyik troll korábbi szavait idézzem, nem kritikára. Minek is, a kritikáknak úgysincs sok értelme ha felém fogalmazzák meg...)

Jópofa amúgy egy effélét leprogramozni. Az elemi (skalár) típusokkal nem volt semmi baj, azok mind beférnek egy 8 bájt hosszú unionba. A string azonban nálam értelemszerűen egy "rather complex" objektum. Van leírórésze meg a satöbbi és a minden. Ő nem fér be 8 bájtba, csak a pointere. Azaz, egy ilyen stringkifejezés-kiértékelő leprogramozása közben nem csak arra kell figyelni hogy a kiértékelő önmagát rekurzívan hívogatja (legalábbis megteheti, alkalomadtán) hanem mert stingről azaz bonyolult objektumról van szó, okvetlenül meg kell hívni közben mindenféle konstruktorokat, destruktorokat, másolókonstruktorokat stb, már ha megengeditek hogy e függvényeket így nevezzem, a C++ nyelv nomenklatúrája szerint, még akkor is ha én sima C nyelven programoztam le a Perit. Mégis, egy ilyen bonyolult objektumnál ezt az egész mindenséget „emulálnom” kellett.

Ha valaha még visszatérnék a C++ programozásához, tuti hogy annak a logikáját is jobban ismerném/érteném ezek után.