[HK] Name conventions

WARNING: Ez a blogbejegyzés a saját fejlesztésű programnyelvemről szól! Továbbolvasása kiskorúaknak még nagykorúak felügyelete mellett sem ajánlott! A kockázatokkal és mellékhatásokkal kapcsolatban kérdezze meg pszichológusát vagy pszichiáterét! Na meg azokat akik már a temetőben fekszenek.

First of all, úgy döntöttem egészen addig nem nyitok új blogbejegyzést a nyelvemről, amíg a hozzászólások száma nem nő az elviselhetetlenségig, tehát legalábbis 200...300 körülire. Azaz aki követni akarja, „iratkozzék fel” rá...

 

Na és most a lényeg. Legújabb nyelvem neve (egyelőre legalábbis): Peri. Aki nem tudná, ez ángliusul olyasmit jelent hogy „jó tündér”.

E nyelv szintaxisa nagyon hasonló a korábbihoz ami sokat szerepelt itt, s aminek neve Furor volt. De nem kompatibilis vele teljesen, csak úgy 80 százalék körül. Most nem akarok belemenni a részletekbe, nem ez a lényeg. Hanem az, hogy a core készen van, de a core önmagában még csak nem is Turing-teljes. Ahhoz hogy az legyen, kellenek bizonyos külső libek, ezek közül a "standard" nevű lib megvan már, azzal együtt már Turing-teljes. Készen van a Math lib is, a mindenféle extra matematikai funkciók számára, amik főleg mindenféle lebegőpontos függvények. Készen van a dir lib is, a directorykezelésre.

Mindez nagyon szép és jó, de most jön a problemusz. Most jönne az str lib (vagy legyen a neve string, teljesen kiírva a szót? Mit gondoltok?). Ebben mindenféle stringmanipulációs függvények lennének természetesen.

E lib is megvan lényegében, bár le kell tesztelnem mert egyszerűen átemeltem a Furorból. Vélhetőleg azonban jó lesz, legfeljebb kisebb átalakításokat kell végezni rajta. A gond ott rejtezik, hogy MI LEGYEN AZ EGYES FÜGGVÉNYEK NEVE.

Nyilván, a libraryban a lehetőségem kötött, ott csak alfanumerikus karakterek lehetnek a függvénynévben, mert a C azt fogadja el. Azonban hála az általam írt interfésznek, ez tökmindegy, mert magában a programnyelvemben (az abban írt szkriptben) nem látszódnak az eredeti nevek a libraryban, így tetszőleges mnemonikot kaphat az adott funkció. Például vegyük a substring képzését. Tegyük fel ennek a neve a libraryban ez:

mysubstr

Ennek ellenére, a peri kódban e szó helyett használhatom akár ezt a szimbólumot is:

|_|_|

Na és ezt épp azért írtam példának mert már majdnem így döntöttem hogy legyen ez a substring szimbóluma, amikor eszembe villant hogy Oh my God, megint mire készülök... jön majd a kritika hogy a nyelvem megtanulhatatlan meg minden...

Ekkor döntöttem úgy hogy megírom e blogbejegyzést. Azért, hogy az ilyen bakikat elkerüljem. Mert elismerem, tényleg hajlamos vagyok rá hogy a fantáziám elszaladjon igen messze a realitásoktól... ez nagyon jó a regényeimhez, de nem biztos hogy oké a programozáshoz.

Szóval most azt szeretném, ha kapnék egy rakás tanácsot, hogy egyes funkciókat (amik nem a core részei), főleg a stringkezeléssel kapcsolatosakat, miként nevezzem el a nyelvemben. Mint fentebb bemutattam, tetszőleges karakterek használhatóak, minden és bármi ami benne van az Unicode táblában, akár ékezetes betűk is, de van egy olyan érzésem hogy - esetleg egészen speciális kivételektől eltekintve - jobb ha megmaradunk az angol ABC betűinél. De majd ti eldöntitek.

Tehát konkretice: mit javasoltok a következő funkciók neveinek:

—substring képzése

—string megfordítása helyben

—string első karaklerének elhagyása

—string utolsó karakterének elhagyása

—egy karakter hozzáfűzése a string végéhez.

—dissect: stringből egy rész kihagyása.

—Egy string beszúrása a string egy adott pozíciója ELÉ, illetve azon pozíció UTÁN.

—Annak vizsgálata, egy string tartalmaz-e egy másik stringet a belsejében

—Egy karakter első előfordulásának keresése a stringben.

—A string karaktereinek balra vagy jobbra léptetése (rotációja) .

—A string karaktereinek kis- illetve nagybetűssé alakítása.

—A string feltöltése egy adott karakterrel.

—String előállítása egy adott karakter n-számú ismétlésével.

—A string balra-, jobbra-, illetve középre igazítása egy adott hosszúságú mezőben, a maradék közöket szóközzel feltöltve, szükség esetén a kilógó vég csonkolásával.

—A string balra igazítása az MC-ben szokásos módon, amikoris ha a string hosszabb mint a megadott mezőhossz, akkor az elejét és a végét látjuk, és középen van kihagyva a bele nem férő mennyiség, s ezt egy ~ karakter jelöli.

—A string elején levő whitespace karakterek lehagyása.

—A string végén levő whitespace karakterek lehagyása.

—A string elején és végén levő whitespace karakterek lehagyása.

—A stringben levő összes whitespace karakter szóközre cserélése.

—A stringben levő összes whitespace karakter lecserélése szóközre úgy, hogy az egymás utáni whitespace karakterek csoportja egyetlen szóközzel van helyettesítve.

—Annak vizsgálata hogy a string végén egy / jel van-e, s ha nem akkor kiegészíti e jellel a stringet.

—Annak vizsgálata hogy a string végén egy újsor jel van-e, s ha nem akkor kiegészíti e jellel a stringet.

—Annak vizsgálata, a string végén újsor karakter áll-e, s ha igen, akkor azt lehagyja.

—Az összes C stílusú azaz // -el kezdődő vagy /* ... */ közti megjegyzés eltávolítása a stringből.

—File beolvasása a stringbe.

—A string stringtömbbé alakítása, úgy, hogy a stringtömb egy sorába az kerül amit újsor karakter zár le.

—String kiiratása fájlba, UTF-8 formátumban.

—Egy karakter előfordulásainak száma a stringben.

—A string szavakra bontása. Azaz e művelet eredménye egy stringtömb lesz aminek minden eleme egy szó. Szó az amit whitespace karakterek határolnak (vagy a string legeleje vagy vége).

Egyelőre ennyi, de nem kizárt hogy lesznek még kérdéseim így nevekkel kapcsolatban. Nem, nem kell segítség nekem a programozáshoz, azt megoldom magam is, sőt az itt leírt funkciók majdnem mindegyike máris készen van. Viszont sajnos az elnevezéseket illetően néha valóban nagyon elborul az agyam, ezt magam is elismerem. Remélem kapok sok jó ötletet amiből aztán válogathatok.

Hozzászólások

"Peri. Aki nem tudná, ez ángliusul olyasmit jelent hogy „jó tündér”."
 

Ennek semmi köze az angolhoz, ez egy perzsa kifejezésből ered.

Nem tudok perzsául. Én egy nagy angol szótárban találtam e szót, az Országh-féle szótárban, ami azért meglehetősen híres még manapság is. Ettől persze még lehet perzsa eredetű, na és? Az angol temérdek szót vett át más nyelvekből. Lehet hogy ezt is. Nem számít, nekem legalábbis tökmindegy.

De én még abban is benne vagyok hogy legyen más neve a nyelvnek, ha akadnak jó tippek rá és valamelyik jobban megtetszik nekem mint a peri, akkor az lesz. Ez a szememben egy sokadrangú részletkérdés. Ha a nagyérdeműt mégis ez izgatja, lehet rajta ötletelni, nem zárkózom el a változtatástól, láthatod...

dehat furcsimurcsiban nem tudtunk irnni uj OSt, te meg mar uj nyelvet csinalsz?:(((((((

Ez a nyelv amit most írok, lényegében maga a Furor, csak:

1. Átneveztem

2. Mindent ami nem abszolút létszükséglet legalább az elinduláshoz és az include állományok megemésztéséhez, kiszórtam külső libekbe

3. Néhány teljesen agyament szintaxist kicseréltem emberbarátabb akármikre (de ettől még elég fura maradt, csak hát azért mégis kissé jobb...)

4. Még sokkal jobb lett az interfész ami összekapcsolja a core-t a librarykban definiált cumókkal

5. Épp ma javítottam ki egy... na nem hibát, tudtam róla rég, de mondjuk hogy hiányosságot: eddig a finite loop-ok nem voltak használhatóak úgy, hogy a loop-ot tartalmazó függvényt rekurzívan meghívjuk a loop-on belül. Mostantól ez a korlátozás megszűnt. Igaz hogy ezzel eléggé agyonbonyolódott a ciklusváltozók kezelése a libraryban, mert mostantól nem a kód tokeneiben tárolódnak hanem egy veremtárban, de ez az én bajom és annyi baj legyen: készen van, jól működik, s nyelv szintaktikája semmit se változott, csak egy megkötéssel kevesebb!

6. Nem kompatibilis a Furorral, de nagyon könnyű átírni rá Furor programokat, mert csak kevés helyen kell változtatni a kódon.

7. LEHET benne OS-t írni! Csak felesleges. Igaz hogy volt régen ilyen tervem, de letettem róla. Túl nagy meló, ami azt jelenti hogy sok időt venne el a regényírástól.

8. Lassabb mint a Furor: a benchmarkok szerint nagy általánosságban kb 20-szor lassabb a natív kódnál, azaz durván kétszer lassabb mint a Furor (kevesebb mint kétszer...), ami azonban nagyon jó eredmény mert eredetileg úgy saccoltam hogy 25-ször lesz lassabb mint a natív kód. Ez a lassulás amiatt történt mert minden libekben van, s így a funkcióhívásoknál ugye a rendszerstack van matatva ami időbe telik. Cserébe azonban messze sokkal jobban személyre szabható mint a Furor.

Íme 2 példaprograny: ez a pí értékét számítja ki iterációval:

###sysinclude standard.uh
tick sto clock1
#d
0. sto p 1. sto n 1. sto s
3000000 {{ s+/- n++++ / sum p }}
4. prd p
tick @clock1 #g -
."idő = " print ." tick\n"
."Pí közelítés = " p #d printnl
end
{ „clock1” }

Ez meg a prímszámok mennyiségét számolja össze egy intervallumban, az Eratoszthenészi szita módszerét alkalmazva:

###sysinclude standard.uh
tick sto startingtick
#g 100000 sto MAX
@MAX mem !maximize sto primeNumbers
one count
2 0 sto#s primeNumbers
2 @MAX külső: {{ ,
@count {{
{{}}§külső {{}} primeNumbers[] !/ inv { {{<}}§külső }
}}
// {{}} gprintnl  // A talált prímszám kiiratásához kommentezzük ki e sort
{{}} @count++ sto#s primeNumbers
}}
@primeNumbers inv mem
."Time : " tick @startingtick - print ." tick\n"
."Prímek száma = " @count printnl
end
{ „MAX” } { „startingtick” } { „primeNumbers” } { „count” }

 

Note: nem a te kedvedért írtam e választ, te nem érdemled meg, hanem a többieknek, az esetleges érdeklődőknek. Bár igaz, te is érdeklődő vagy, hiába is tagadod, különben nem enne a fene oda téged mindig a topikjaimba. De annyi baj legyen, kezdem úgy vélni, még mindig jobb ha vannak irigyeim meg ellenségeim, mintha egy szürke kis nímand lennék akire senki nem figyel.

Olvasd el mégegyszer amit fentebb írtam... Nota bene, én még tanultam oroszul az iskolában. Emellett, a feleségem kárpátaljai lány, aki anyanyelvi szinten beszél oroszul. (ukránul is).

A lényeg azonban nem ez, hanem hogy nem mész te sokra egyetlen nyelven sem azzal ha szigorúan ahhoz tartod magadat a hétköznapi társalgásban, amit az egyes szavak vagy igeidők vagy akármi jelentéséről és használatáról a TANKÖNYVEKBEN olvashatsz. Most hogy itt az USA-ban élek, legendákat tudnék blogolni százszámra arról, hogy milyen magától értetődő természetességgel szegik meg beszéd közben a legalapvetőbbnek tartott szabályokat is az amcsik, olyanokat elkövetve a beszédjükben amiért habozás nélkül kibasznának mindenkit az alapfokú nyelvvizsgáról is...

Most mondjuk azt, az amerikaiak nem tudnak angolul? NEM. Egyszerűen az angol AZ, ahogy ők beszélik. (legalábbis az amerikai angol). Az meg hogy mi van a tankönyvekben, teljesen más kérdés. Az egy absztrakció, s nem okvetlenül képezi le a valóságot.

Na és hát pontosan ez a helyzet az orosz nyelvvel is. Ma már nem tudok oroszul, de egy időben rendszeresen sefteltem a „lengyelpiacokon”. Ami csak nevében lengyel, volt ott bőven orosz is, ukrán is. Amit mondtak, annak a nyelvnek annyi köze volt az iskoában tanulthoz mint az ómagyar máris siralomnak a mai magyarhoz. Azt első pillantásra tudni lehetett hogy ez valami szláv nyelv... de hogy ez konkrétan orosz lenne, azt elég soká tartott elhinnem...

A sto az kérdő névmás első, másod, harmad és n-ed sorban. És a vicc bizony arról szól, hogy a vizsgázónak halovány lila szellentése sincs arról, hogy aki kérdez, mit is mond valójában.

A nyelvvizsga egy dolog, a "Rigóban" magyar nyelvből is rengetegen megbuknának magyar anyanyelvűek is. Ettől még nem a plebs nyelvtanilag, stilisztikailag botrányos nyelvhasználata kell, hogy a zsinórmérték legyen, hanem az "irodalmi" nyelv, az igényes és választékos, helyesen alkalmazott nyelvi szerkezetekkel operáló nylevhasználat az, amihez a nyelv tanulása és használata során tartani kell magát az embernek, ha csak lehet.

Pedig bizony a "sto" mutatónévmás is néha és némelykor... Ugyanúgy tud funkcionálni mint a magyar "ki" (vagy mi) mely szintén kérdő névmás, de adott esetben simán használtatik "aki" (ami) jelentésben is! (pláne régies szövegekben).

Például: "Az ki odafent vala"...

De hogy épp az orosznál maradjunk, jaj de sokszor hallottam:

"Ja nye znaju sto vi gavaritye"...

azaz: "Nem tudom MIT mondasz".

Itt ebben a kontextusban a "sto" nyilvánvalóan nem kérdőszó hanem mutatónévmás...

És mégegy "szabálytalanság" van e mondatban: a "tudom" azaz znaju szót használják a szabályos "értem" azaz "ponyimaju" helyett...

De akikkel beszéltem, így mondták. Oroszul. Nekik ez volt az orosz nyelv.

De különben is kár ezen rugóznunk. Tetszik vagy se neked, egy nyelv igenis AZ amit az emberek nagy többsége beszél. Vannak természetesen valóban holmi stilisztikai „rétegei”, ez igaz. De attól még az is a része ami neked/nekem nem tetszik. Ami itt az USA-t illeti, nekem elsősorban épp ehhez a „plebshez” kell igazodnom, mert velük kell kommunikálnom, és annak esélye hogy ők tanuljanak meg magyarul a kedvemért, nulla alatti. Ugyanez lenne a helyzet ha a ruszkiknál dolgoznék.

Érdekes egy pojáca vagy hogy azt hiszed, te jobban tudod a magyar nyelvet mint én, a magyar anyanyelvű író...

De különben is, amit ideböffentettél, még véletlenül se ellenérv arra amit én írtam fentebb. Ja persze, mert szakmai érved nincs... Nem tudom, miért nem ajánlottad fel a szolgálataidat Trumpnak, jól megértettétek volna egymást, ő is olyan hogy ha nincs ellenérve, inkább trollkodni kezd. A paprikajancsik és bohócok szokásos eszköztára. De csináld csak ha égni akarsz.

>pojaca, troll, paprikajancsi, bohoc

:(

Igazabol tenyleg nem tudok oroszul, de kicsit meghokkentett, hogy ugy ugrottal be ebbe a szalba, hogy elkezdted fejtegetni mit es hogyan ertett a viccbeli rendor.

De nem is egetem magam tovabb. o/

Nézd, vedd észre kérlek hogy TE voltál az aki belém kötöttél, nem én kötöttem tebeléd!

Ráadásul még igazad se volt, mert ha nekem nem hiszel nézz már utána légy oly kedves hogy a "Ja nye ponyimaju sto vi gavaritye" egy tökéletesen helyes orosz mondat, és tényleg azt jelenti hogy "nem értem amit mondasz". Na most ezesetben pedig a "sto" ebben a kontextusban azt jelenti hogy "amit". Ha azt jelenti akkor mutatónévmás. (megjegyzem, nemcsak hogy mutatónévmás de még tárgyesetben is van). Ezt figyelembe véve a viccben mondott orosz szöveg általam nyújtott értelmezése tökéletesen korrekt. Nem zárom ki, hogy létezhet más értelmezése is, de ettől még az enyém (is) korrekt. És ehhez NEM kell még oroszul tudni se, szinte semennyire se, csak ezt az egyetlen mondatot tudni oroszul... Annyi pedig talán sokak fejében megragadt az iskolai tanulmányaik idejéből.

De nem is ez az érdekes az egészben, hanem hogy te nem elégedtél meg azzal hogy itt megállj, hanem már a postod legelejét is úgy vezetted fel, hogy én szerinted még magyarul se tudnék... Miért, TE talán jobban tudsz magyarul mint én az író?! Ember, nekem születésemtől fogva a magyar az anyanyelvem (mint vélhetőleg neked is), de veled ellentétben én szorgalmasan gyakoroltam is az alkalmazását félszáznál is több regény megírása közben! Te hányat írtál?!

Most persze jöhetsz azzal hogy szerinted azok a regények nem ütnek meg ilyen vagy olyan művészi mércét, hogy neked nem tetszenek stb (bár megtippelem, lehet hogy egyiket se olvastad...), de MÉG HA ez igaz is volna, akkor is tény marad a tény hogy ezeket megírtam, azaz közben gyakoroltam jó sokat a (magyar) nyelvet!

Amennyiben tehát kettőnk nyelvtudását összehasonlítjuk, csakis én kerülhetek ki belőle győztesen. Holtbiztos hogy egy rakás olyan (főleg régies) szófordulatot ismerek amiről te az életedben soha nem hallottál még!

Legjobb esetben is csak olyan területen tudnál megfogni engem, hogy valami rém ritkán szükséges helyesírási szabályt nem ismerek (vagy sokkal valószínűbb hogy ismerem ugyan de tudatosan mellőzöm mert nem értek egyet vele...), jóeséllyel ez is olyan szabály ami az én iskoláskoromban másképp volt még de azóta az okostojások megváltoztatták én azonban nem frissítettem az ismereteimet. Vagy igen, de a régi szabályzás jobban tetszik... Ilyesmire megvan az esély, igen, épp csak ennek semmi köze a NYELV ismeretéhez, a nyelv ugyanis nem azonos az írott formájával, pláne nem annak a helyesírásával!

Te meg itt jössz azzal hogy én, az ÍRÓ nem tudom a saját anyanyelvemet... Elég pökhendi állítás tőled... Továbbá, ezen állításodra még csak példát se hoztál.

Még ha csak az angol illetve orosz nyelvet említetted volna, hitelesebb lett volna a támadásod ellenem. Így azonban tényleg nevetséges.

De figyelj csak. Én nem szeretek veszekedni. Nem köthetnénk békét, mondd? Nem mintha félnék tőled. De nem szeretem a trollkodást, de a végtelen, sehova se vezető vitákat se. Én biztos nem fogok ellened támadni, ha te se teszed ezt ellenem, mindjárt barátságosabb lenne a fórum. Nem tudom miért vagyok ellenszenves a számodra, nem emlékszem rá hogy valaha is bántottalak volna, elsőként biztosan nem. Mi lenne ha ahhoz tartanád magadat te is hogy nem kötsz belém ELSŐKÉNT?! Ez olyan könnyű! S akkor mert én se kötök beléd elsőként, mindjárt minden szebb volna! Élni és élni hagyni, tudod, milyen nemes is ez az elv!

Egyáltalán, én nem értem miért van az hogy az internetes kommunikáció mindenkiből a legrosszabb énjét hozza ki, a trollt, a bunkót, a vadállatot. Miért van az hogy ilyen fórumokon oly végtelenül könnyű ellenségeket szerezni, de barátokat lehetetlen, vagy legalábbis milliószor nehezebb?!

Ez mindenesetre semmiképp se válik az emberi faj díszére...

Örülök hogy valami egészen speciális billentyűzetet használsz ahol nem egymás mellett van az "a" és az "s" billentyű, és így azon szerencsések közé tartozol akik sosem keverik össze őket véletlen elütésnek miatta és okából kifolyólagosan.

Hálás szívvel köszönöm hogy felhívtad a nagyra becsült publikum figyelmét erre a borzasztó és mindenképp közérdekű, s óriási figyelemre teljes joggal számot tartó hibára, mely nyilvánvalóan érthetetlenné teszi a közölni kívánt üzenet mélyértelmét!

Figyelmetlenségem miatti önbüntetésként ma este lefekvés előtt megkeresem a vonatkozó postban az összes jambikus pentametert, csak hogy el ne feledjem, a gondosság a legfőbb erény!

Uff én beszéltem.

It works for me however...

Számomra például egy haskell vagy más funkcionális nyelv tűnik zagyvaságnak, nem is beszélve a rémálmomról, a mysql-ről, ahol mindent igyekeznek belegyömöszölni egyetlen SELECT utasításba, elrejtve a ciklusokat a Felhasználó szeme elől...

De a Perl is zagyvaság első pillantásra, és sok más is. Minden annak tűnik AMÍG MEG NEM ISMERJÜK.

Attól tehát hogy neked katyvasznak tűnik, még lehet jó. Hogy számodra katyvasz az csak egy dolgot bizonyít: még nem ismered. Hogy nem ismered még, az persze nem a te hibád, de akkor sem alap a lebecsülésre.

"nem is beszélve a rémálmomról, a mysql-ről, ahol mindent igyekeznek belegyömöszölni egyetlen SELECT utasításba, elrejtve a ciklusokat a Felhasználó szeme elől"

Azért azt tudod, hogy az SQL az picit nagyobb "halmaz", mint a mysql, és bizony nagyon-nagyon-nagyon jól struktúrált lekérdezőnyelvről van szó, ahol olyan, hogy "ciklus, ami végigmegy a..." per definitem nincs - ugyanis nincs rá szükség.

ahol olyan, hogy "ciklus, ami végigmegy a..." per definitem nincs

Na épp ez a bajom hogy nincs benne ciklus. Erről írtam fentebb. Emiatt gyűlölöm és utálom. Minő szerencse, nem is kényszerít senki se arra hogy használjam...

Én szeretem a ciklusokat. A programnyelvemben is ESZMÉLETLEN gondot fordítottam rá hogy remekül legyenek interpretálva, gyorsak legyenek, és fel legyenek turbózva minden ficsőrrel mi szem-szájnak ingere...

Most erre mondhatod hogy látszik, az én nyelvem „alacsony szintű” de az SQL „magas szintű”. Oké, lehet. De soha nem is mondtam olyasmit hogy a célom egy MAGAS szintű nyelv létrehozása lenne. A célom hogy legyen egy nyelv ami az „enyém”, és olyan legyen ami NEKEM tetszik.

Lehet, hogy neked hiányzik, de nem kell az SQL-be for meg egyéb ciklus - ugyanis a nyelv nem ilyesmire való - de mutass légyszives egy olyan feladatot, ahol vannak az adatbázisban táblák, azokban rekordok, és azoknak a kezeléséhez must have for ciklust használni. Van, amikor a lekérdezés eredményén végig kell menni, és csinálni velük valamit - de az már _nem_ az SQL "réteg", hanem a hívó oldalon elvégzendő feladat.

Procedurális kiegészítésben persze, hogy van, de az nem a "natúr" sql, aminek egy dialektusát a mysql is "beszéli". (Mostanság lenne 20 éves az első production rendszerbe került Pl/SQL kódom, ha létezne még az a rendszer, aminek a fejlesztésébe anno nyakig benne voltam...)

MySQL: https://dev.mysql.com/doc/refman/5.7/en/loop.html

DB2 SQL: https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src…

Teradata SQL: https://docs.teradata.com/reader/CeAGk~BNtx~axcR0ed~5kw/2wEt5W8GPWOquBp…

Itt ezt irjak: FOR is ANSI/ISO SQL:2011-compliant. LOOP is ANSI/ISO SQL:2011-compliant.

Mivel az ANSI/ISO SQL:2011 szabvanyt nem talaltam meg hirtelen ingyenesen (fizetni meg biztosan nem fogok erte), elhiszem nekik hogy nem hazudnak :)

Ha az ansi/iso compliance nem "natur" SQL, akkor nem tudom a szabvany melyik reszhalmazat erted "natur" SQL-nek. De igazabol mindegy, regen nem volt, mostmar van ciklus sqlben. Tovabblepett a vilag.

Na ez erdekes. Elonye viszont, hogy nyelvfuggetlen, es emiatt ertheto az algoritmus logikaja.

Sokszor igaz, hogy valamit le lehet irni szepen egy funkcionalis nyelvben ket sorban, de nem feletetlen er annyit, ha 10-bol 8 szoftverfejlesztonek fel oran at kell magyarazni peldakkal, hogy ott mi tortenik.

Raadasul altalaban azok a legjobbak a funkcionalis nyelvek eszkoztaranak a kezeleseben, akiknek a legkevesbe szokott erzekuk lenni azt jol el is magyarazni.

Raadasul altalaban azok a legjobbak a funkcionalis nyelvek eszkoztaranak a kezeleseben, akiknek a legkevesbe szokott erzekuk lenni azt jol el is magyarazni.

Sajnos ez nagyon igaz.

Sokszor igaz, hogy valamit le lehet irni szepen egy funkcionalis nyelvben ket sorban, de nem feletetlen er annyit, ha 10-bol 8 szoftverfejlesztonek fel oran at kell magyarazni peldakkal, hogy ott mi tortenik.

Nem szabad minden syntactic sugart ész nélkül használni. :)

Egyébként nem a tömörség miatt jó a funkcionális megközelítés, hanem mert olyan dolgokra ad lehetőséget, amit nélküle körülményesebben lehet csak megcsinálni. 

nem is beszélve a rémálmomról, a mysql-ről, ahol mindent igyekeznek belegyömöszölni egyetlen SELECT utasításba, elrejtve a ciklusokat a Felhasználó szeme elől

Pedig ha tudnák, hogy sok esetben szebb/hatékonyabb több SELECT egymásba ágyazva, mint egy gigantikus query. :)

NOTE: Pont ezek miatt amit leírtál lenne értelme verziókövetőt használni... legalább lenne historyd a mau-ig(vagy mi volt) visszamenőig, látnád milyen probléma miatt mit csináltál, stb. Ez amit csinálsz kínlódás, meg önszopatás. 2020-ban másolgatsz innen-oda, meg átnevezed és átírod. jajj

Miért nem szánsz 1 hetet rá, hogy megtanulj egyet? Írhatsz abból is egy könyvet. Annak máris nagyobb értéke volna a közösség szemében, mint bármilyen progi nyelvnek. TIPP: git-ből van ezer leírás, ha rászánnád magad: mercurial. Szívesen olvasnék róla.

Miért nem szánsz 1 hetet rá, hogy megtanulj egyet?

Őt nem így kell motiválni. :) Azt kell mondani neki, hogy írjon egy saját verziókezelőt a saját nyelvén, ami már elvileg képes egy ilyen feladatra, hiszen alapvetően string-műveletek szükségesek. Közben egy csomó mindent tanulhat a verziókezelők működéséről, ami motiválhatja a kódolás elvégzésére.

Basszus, ez nem is rossz ötlet, sőt REMEK ötlet! Előbb ugyan vélhetőleg igenis text editort írok majd a nyelvemen, de attól még az ötleted igenis remek!

És igen, igazad van, valóban valami efféle a módszer arra ami nálam beválik mint „helyes motiváció”... Tényleg kezdesz kiismerni engem!

És igen, abban is igazad van hogy úgy lehet IGAZÁN megismerni valamit, hogy az ember igyekszik megalkotni, az alapoktól...

Az az igazság hogy ez olyan mértékig a Furor kódbázisára épül, hogy két hétbe se tellett összedobnom mert egy rakás mindent készen átemelhettem belőle. Mondjuk annyiból nincs még kész hogy a Furorhoz írtam egy sereg libet, ezek többségét még nem emeltem át, nem ellenőriztem le hogy működik-e a Perivel, s ha nem akkor mit kell változtatnom rajta. De igazán nem lesz nagy meló ez se, csak nem akarom elsietni, s azért nem mert a kód hiába jó, ha nem tudom mi legyen a NEVE az egyes funkcióknak a programnyelvemben... na ez az amiért itt tanácsot kérek. És igazán hozzáállhatnál a kérdéshez építő módon is trollkodás helyett. Szégyen amit művelsz, tényleg, főleg mert ha jól tudom valamiféle oktató vagy, tanár, ilyesmi... Erre itt egy fickó - én - akiről le se tagadható hogy tele van lelkesedéssel hogy alkosson és tanuljon vagy legalábbis gyakoroljon informatikai témában, s te, akinek az lenne a dolga hogy az efféle lelkesedést bátorítsa és segítse a tanulókat, te inkább mindent megteszel hogy elcsüggeszd az illetőt! Az ilyen mentalitású ember a tanárok szégyene. Ezt műveled a diákjaiddal is?! A szerencsétlenek...

És még felesleges is amit csinálsz mert látod: nem bírsz eltéríteni a célomtól.

—substring képzése

substring

—string megfordítása helyben

reverse

—string első karaklerének elhagyása

tail

—string utolsó karakterének elhagyása

head

—egy karakter hozzáfűzése a string végéhez.

append

—dissect: stringből egy rész kihagyása.

removeRange

—Egy string beszúrása a string egy adott pozíciója ELÉ, illetve azon pozíció UTÁN.

insertBefore, insertAfter

—Annak vizsgálata, egy string tartalmaz-e egy másik stringet a belsejében

contains

—Egy karakter első előfordulásának keresése a stringben.

firstIndexOf

—A string karaktereinek balra vagy jobbra léptetése (rotációja) .

shift/rotate

—A string karaktereinek kis- illetve nagybetűssé alakítása.

toLower, toUpper

—A string feltöltése egy adott karakterrel.

fill

—String előállítása egy adott karakter n-számú ismétlésével.

repeat

—A string balra-, jobbra-, illetve középre igazítása egy adott hosszúságú mezőben, a maradék közöket szóközzel feltöltve, szükség esetén a kilógó vég csonkolásával.

padLeft, padRight, padMid (tippre ez inkabb a megjeleniteshez tartozik, nem a string fuggvenykonyvtarba)

—A string balra igazítása az MC-ben szokásos módon, amikoris ha a string hosszabb mint a megadott mezőhossz, akkor az elejét és a végét látjuk, és középen van kihagyva a bele nem férő mennyiség, s ezt egy ~ karakter jelöli.

fit (elozohoz hasonloan szerintem nem string fuggvenykonyvtarba valo)

—A string elején levő whitespace karakterek lehagyása.

trimStart/trimLeft

—A string végén levő whitespace karakterek lehagyása.

trimEnd/trimRight

—A string elején és végén levő whitespace karakterek lehagyása.

trim

—A stringben levő összes whitespace karakter szóközre cserélése.

replace

—A stringben levő összes whitespace karakter lecserélése szóközre úgy, hogy az egymás utáni whitespace karakterek csoportja egyetlen szóközzel van helyettesítve.

replaceGroup

—Annak vizsgálata hogy a string végén egy / jel van-e, s ha nem akkor kiegészíti e jellel a stringet.

ensureLastCharacter/ensureEnding

—Annak vizsgálata hogy a string végén egy újsor jel van-e, s ha nem akkor kiegészíti e jellel a stringet.

ensureLastCharacter/ensureEnding (ugyan az mint elobb, csak mas karaktert illeszt a string vegere)

—Annak vizsgálata, a string végén újsor karakter áll-e, s ha igen, akkor azt lehagyja.

trim (ugyan az a muvelet, csak mas karaktert vag le a string vegerol)

—Az összes C stílusú azaz // -el kezdődő vagy /* ... */ közti megjegyzés eltávolítása a stringből.

removeCStyleComment (ez olyan specialisnak tunik, hogy nem raknam a string fuggvenykonyvtarba)

—File beolvasása a stringbe.

readFromFile (szerintem ez file muvelet, nem a string konyvtarba valo)

—A string stringtömbbé alakítása, úgy, hogy a stringtömb egy sorába az kerül amit újsor karakter zár le.

split/tokenize

—String kiiratása fájlba, UTF-8 formátumban.

writeToFile (szerintem ez file muvelet, nem a string konyvtarba valo)

—Egy karakter előfordulásainak száma a stringben.

count

—A string szavakra bontása. Azaz e művelet eredménye egy stringtömb lesz aminek minden eleme egy szó. Szó az amit whitespace karakterek határolnak (vagy a string legeleje vagy vége).

split/tokenize (ugyan az a muvelet mint elobb, csak mas karakter szerint tortenik a bontas)

Na végre egy érdemi hozzászólás, nagyon szépen köszönöm!

Találtam is benne jópár olyan dolgot ami tetszik. Lennének azonban „vitatott pontok” is. Mindenekelőtt: Bevallom őszintén, nekem a hátam borsódzik a z olyan kulcsszavaktól ahol a szó közepén hirtelen egy nagyBetű található, de különösen akkor, ha a szó eleje meg kisbetűvel kezdődik. Hadd kérdezzem meg a nálam tájékozottabbakat, lehetne-e ezellen kitalálni valami más módszert? Néha én is használok ilyesmit, de ott legalább akkor az úgy van hogy a szó legelső betűje is mindig Nagy betű... de tulajdonképpen ezt az egész izét hogy több értelmes szóból állítsunk össze egy kulcsszót, kerülném ha lehet. Azaz tömören: én előnyben részesíteném az egyszavas mnemonikokat, amennyiben találunk kellő számút. Szóval nem zárkózom el végleg a többszavasoktól, de inkább csak végszükség esetére...

A "replace" kulcsszó szerintem inkább olyasmire lenne jó hogy a stringben egy részletet kicserélni egy másik stringre, és nem lenne okvetlen szükséges hogy a kicserélt rész az újjal azonos hosszúságú legyen. De itt meg akkor az van hogy meg kéne különböztetnünk 2 alesetet:

1. A keresett stringrészlet ELSŐ előfordulását cseréli csak le.

2. Minden előfordulást lecserél.

Azt mindenképp elfogadom a javaslatodból, hogy akadnak funkciók a felsoroltak közt amik inkább egy másik libbe valók lennének, aminek legyen a neve mondjuk "file". Semmi akadálya annak hogy áttegyem őket abba. A baj az, hogy akkor meg az a lib olyan kell legyen ami úgyis behúzza magának a stringlibet, minthogy kell neki egy rakás cumó ami az én speciális stringosztályomat kezeli. Nálam ugyanis a stringek elemei szigorúan 8 bájtos "unsigned long long" elemeket tartalmaznak, pontosabban egy uniont ami ilyen hosszú, s ebben tárolják az Unicode értékeket...

Tudom hogy pocséklás, ellenben eszméletlenül hatékony. Nálam végső soron ugyanis minden memóriaallokáció VÉGSŐ SORON egy ilyen stringre mutató pointerrel tér vissza. Minden magasabb „osztály” erre a stringfajtára épül nálam. Tehát azért 8 bájtos a tárolási egység mert ennyi bájtba minden elemi izémizé belefér ami a 64 bites rendszerekben lenni szokott. (Ettől még persze van lehetőség hogy ilyen stringet átalakítsunk char* -gá, a kernel meg egyéb „kincstári” rutinok számára...)

Ha a C stílusú kommentek kiszűrését külön libbe teszem, jóeséllyel az lesz abban a libben az egyetlen függvény. Nem nézne ez ki rosszul? Vagy, esetleg mit lehetne még beletenni akkor abba a libbe? Várom a tippeket!

a hátam borsódzik a z olyan kulcsszavaktól ahol a szó közepén hirtelen egy nagyBetű található ... de tulajdonképpen ezt az egész izét hogy több értelmes szóból állítsunk össze egy kulcsszót, kerülném ha lehet

Ez konvencio kerdese, termeszetesen a sajat nyelveddel azt csinalsz ami neked tetszik, javaslatokat kertel :) Van olyan nyelv ahol ez a kisNagyBetu() a konvencio, van ahol NagyBetu(), van ahol TeLjeSenMindEGY() mert nincs a kis-nagybetu megkulonboztetve.

Szemely szerint jobban szeretem az olyan nyelveket, ahol a fuggveny nevebol kiderul mit csinal a nelkul, hogy dokumentaciot kene olvasnom (ertelmes szavakbol osszerakott nevek vs mnemonikok). De megint, a sajat nyelvedet ugy alakitod, ahogy neked tetszik, nyugodt szivvel ne fogadj meg semmit abbol amit irok/irtam :)

A "replace" kulcsszó szerintem inkább olyasmire lenne jó hogy a stringben egy részletet kicserélni egy másik stringre, ... De itt meg akkor az van hogy meg kéne különböztetnünk 2 alesetet:

Ez nem passzol az elobb emlitett "mnemonik kivanalmaidhoz", de: replacefirst, replaceall. Illetve whitespacek kicserelesere: replacews, replacewsgroup.

Ha a C stílusú kommentek kiszűrését külön libbe teszem, jóeséllyel az lesz abban a libben az egyetlen függvény. Nem nézne ez ki rosszul? Vagy, esetleg mit lehetne még beletenni akkor abba a libbe?

Altalanos celu programozasi nyelveknel altalaban "elemi" muveleteket raknak a nyelvhez tartozo fuggvenykonyvtarakba, es azokra az elemi muveletekre epitik a komplexebb muveleteket (mint pl. a C stilusu kommentek kiszurese), ennek megfeleloen vannak felosztva a libek es azok fuggosegei. Egyeb nyelveknel pedig elrejtik az elemi muveleteket es a komplexebb muveleteket biztositjak keszen a programozo szamara (pl SQL-nel sem kell azzal foglalkoznod hogy kerul a tartos tarrol a memoriaba az adott sor amin a muveletet fogod vegezni). De erre is vannak kivetelek, igazabol toled fugg hogy milyen megkozelitesben hiszel.

Hogy jol nez-e ki, az attol fugg mit tartasz jonak. Szemely szerint a string konyvtarba csak elemi muveleteket raknek, amikor egy konkret karakterrel dolgozol, azt mar a string konyvtarra epulo kulon konyvtarba raknam. Pl.: string konyvtarba a "A string stringtömbbé alakítása", aminek bemeneti parametere lenne a karakter(ek) ami menten fel akarod bontani a stringet. A stringprocessing konyvtarba pedig "A string stringtömbbé alakítása újsor karakter menten" es "A string stringtömbbé alakítása whitespace karakterek menten", ahogy ide kerulne a "c stilusu kommentek torlese" is, stb.

Félre ne érts, nem kötekedni akarok: egyszerűen bevallom mélységes zöldfülüségemet hogy tényleg és igazán nem nagyon értem mi a különbség a "string" könyvtár és a "stringprocessing" könyvtár szándékolt célja közt. Mi az az egyszerű kritérium, ami alapján megkülönböztethetném őket? Úgy értem, ami alapján eldönthetném valami egyszerű módon, hogy egy adott funkció melyikbe kerüljön?

Van például egy remek függvényem, ami egy egész számot átalakít stringgé, de úgy, hogy ezres csoportonként beszúr a stringbe egy-egy színszekvenciát, azaz inkább úgy mondom escape-szekvenciát, hogy terminálra kiíráskor az egyes számcsoportok eltérő színben jelenjenek meg. És az ilyen funkciókkal totál meg vagyok zavarodva hogy hova tegyem: egyrészt ugye ennek köze van a stringekhez hiszen egy string lesz az eredmény. Másrészt, a színekhez is köze van - legyen valami "color" library is?!` De a számokhoz is köze van, mégse merném a "math" libbe beletenni... Vagy ez most akkor valami konverziós library része volna inkább? Netán kerüljön a "terminal" libbe?! Vagy...?

Ez nekem tényleg nagy gond, eddig csak a nyelv leprogramozásával foglalkoztam, ezen kérdéseket ad-hoc módon oldottam meg, bízva abban hogy „majd kialakul”, hiszen ez könnyű, ez nem programozás, a lényeg hogy működjön,..

És működik is, abban nincs hiba, de kiderül hogy mégse könnyű, mert számos szempont szerint lehet dönteni...

Amiben biztos vagyok, olyan neveket nem fogok alkalmazni hogy az első kisbetű, de aztán van benne valahol nagybetű is. Az még elmegy hogy MindenSzókezdőBetűNagy, de akkor az első is!

Vagy mindegyik kisbetű - bár lehet hogy ekkor nehezebben olvasható.

De ez hogy mi melyik libbe kerüljön, még ennél is nagyobb gond nekem.

Az biztos, a következő libek mindenképp megszületnek, illetve részben meg is vannak:

—standard  - ez nagyon fontos, ebben vannak az alapvető műveletek, meg egypár más dolog is. Enélkül nem is Turing-teljes.

—math (mindenféle olyasmi hogy színusz, négyzetgyök, logaritmus, stb.) Ezzel nincs sok gondom, a lib készen van, s az elnevezések is adják magukat.

—dir Ebben a directorykezeléssel kapcsolatos dolgok vannak, ez is azt hiszem eléggé nyilvánvaló mit hogyan kell nevezni: például filename, filesize, atime, stb.

—args ebben eddig csak 2 függvény van, a nevük argc és argv, egyértelmű hogy mit csinálnak.

—str Ez a string librarym. Na és EZ AZ ahol kezdődnek a nagy problemuszok...

Úgy értem, ami alapján eldönthetném valami egyszerű módon, hogy egy adott funkció melyikbe kerüljön?

Nem tudom van-e erre valami szabaly, ha nekem kene dontenem, akkor hierarchikusan epitenem fel a fuggvenykonyvtarakat. Azt vennem figyelembe, mire vonatkozik a fuggveny, mennyire "elemi" muvelet amit elvegez es az eredmeny mire/hol van hasznalva. Tovabba egy konyvtarba a logikailag osszetartozo fuggvenyek kerulnenek. Ha meg tudod fogalmazni mire valo a konyvtar az sokat segit eldonteni mi valo bele: 

  • math: matematikai muveletek. (es igy mar erezheto, hogy a szam->string konverzio az nem matematikai muvelet)
  • dir: ezt atneveznem io-ra, es akkor fajlrendszer kezelessel kapcsolatos muveletek.
  • str: string vizsgalo es manipulacios muveletek.
  • terminal: megjelenitessel kapcsolatos muveletek. (igy erzesre minden megjelenitest segito fuggveny ide illik, szinkodos szam konverziot es szoveg jobbra-balra igazitast is beleertve)
  • text processing: szovegfeldolgozassal kapcsolatos muveletek.
  • stb..

A nyelv ismerete nelkul nehez ertelmes javaslatot tenni, de en pl valahogy igy csinalnam:

  • "szokozok torlese a string vegerol" - stringen dolgozik, az eredmeny altalanos celu -> string konyvtar
  • "konkret karakter torlese a string vegerol" - stringen dolgozik, az eredmeny altalanos celu -> string konyvtar
  • "utvonal elvalaszto karakter torlese a string vegerol ha van" - stringen dolgozik, specialisan fajlrendszer kezeleshez segedfuggveny-> io(?) konyvtar (io fugg a string konyvtartol)
  • "szam stringge alakitasa" - szamon dolgozik, az eredmeny altalanos celu -> string-be mint "create string from number" az egyszeruseg kedveert, de lehetne magasabb rendu "conversion" konyvtarba is rakni ami ide-oda tud konvertalni a tipusok kozott amit akarsz.
  • "szam stringge alakitasa szinkodok beszurasaval" - szamon dolgozik, az eredmeny csak kijelzesre hasznalhato -> terminal konyvtar (terminal fugg a string konyvtartol)
  • "string tomoritese hogy beferjen x karakterbe" - stringen dolgozik, az eredmeny kijelzesre hasznalando -> terminal konyvtar
  • "string felbontasa tetszoleges karakter menten" - stringen dolgozik, az eredmeny altalanos celu -> string konyvtar
  • "string felbontasa szokozok menten" - stringen dolgozik, az elozo egy specialis esete -> text processing konyvtar(?), text processing fuggene a string konyvtartol. De ilyenre nem is biztos hogy csinalnek kulon fuggvenyt, egyszeruen az elozo fuggveny parameterezesevel helyettesitheto.
  • "fajl soronkenti beolvasasa string tombbe" - fajlon dolgozik, string tombot ad vissza -> io konyvtar (io fugg a string konyvtartol)
  • "c stilusu kommentek torlese" - stringen dolgozik, osszetett muvelet -> text processing konyvtar(?)

De sok minden nezopont kerdese, ha 10 embert megkerdezel nem lepodnek meg ha 12 kulonbozo valaszt kapnal hogyan jo felbontani a fuggvenyeket, es nagyban fugg attol mire helyezed a nyelvben a hangsulyt. Pl. ha a nyelv celja statisztika szamitasok tamogatasa, akkor a "math" konyvtar valoszinu tobb reszre lesz bontva, mig ha szovegfeldolgozas a cel, akkor a "math" konyvtar kicsi lesz, az "str" viszont terjedelmes, stb. Nincs egy igaz megoldas.

Hm, köszi, sokat segítettél...

Annyi bizonyos, a math könyvtárba nem fogok belerakni stringgel kapcsolatos dolgokat, egy darabot se. Tudniillik, nincs szükség rá hogy oda kerüljön a szám stringgé alakítása vagy string számmá alakítása, s azért nem, mert ezek a "standard" könyvtár részei. És azért abba kerülnek (kerültek, már benne vannak) mert a string - mint említettem fentebb - a nyelvemben egy ELEMi típus. Alapból támogava van, mert minden erre épül benne, már a parser illetve tokenizáló rész is ezt a string „osztályt” használja. Eképp, minthogy a standard lib részei az elemi műveletek, mint az összeadás, kivonás stb, ezek ott értelmezve vannak a stringekre is - bár néha furcsán. Az összeadás stringek esetén konkatenálást jelent - ez számos nyelvben így van - ellenben a -- azaz mínuszmínusz postfix operátor például eggyel csökkenti jobbról a string hosszát. Ezt az imént oldottam meg így, jobban tetszik mintha valami bonyolult angol nevet kéne kitalálni erre a funkcióra.

Igenám, de nem akarok mégse minden stringműveletet belegyömöszölni a +standard" könyvtárba. Azokat amiket rá lehet aggatni a megszokott aritmetikai szimbólumokra, azokat igen. A többit azonban nem, ezért kell külön az str könyvtár.

De, amit írtál felosztást, az nagyrészt mégis tetszik nekem. Ha azonban említetted hogy mi a nyelv célja, nos, NEM TUDOM (igazából az egyetlen célja az hogy LEGYEN egy olyan nyelv amit én alkottam, s így nincs szerzői jogi probléma ha szerepeltetem valamelyik regényemben...), de abban azért biztos vagyok hogy miután szkriptnyelv, így messze többször lesz használva stringmanipulációs célokra, beleértve stringtömbökkel való munkát is, mint matematikai feladatokra. Ez annyira így van hogy távlati célom egy text editort írni benne, az meg nyilvánvalóan stringmanipulációs (és terminálos) feladat ugyebár.

Mindegy, a lényeg hogy nagyrészt azért tetszik az általad javasolt felosztás. Például tetszik, hogy ne dir könyvtár legyen hanem "io", Itt nálam már éjfél van, de holnap ennek megfelelően módosítom a dolgokat.

De akkor pár további kérdés.

—Érdemes-e szerinted egy külön "shared" libet is kreálni, amiben a shared memory kezelésének függvényei vannak benne, vagy ez a core része legyen?

—Hova kerüljön a fork() funkció? (meg minden más ami ezzel kapcsolatos). Szimpatizálok például azzal hogy a core része legyen, így a nyelvem alapból támogatná a többszálúság ezen módját, de akkor a core része kell legyen a sharedmemoryval kapcsolatos minden is, mert a fork után a parent és a child process egymással csakis a shared memory szegmenseken át tud kapcsolatot tartani... Netán épp emiatt egyik se legyen a core része, de kerüljenek egyetlen közös libbe? Ha igen mi legyen annak a libnek a neve?

—Aztán, van olyan funkcióm is hopgy kioírni egy stringet a grafikus képernyő (az ablakkezelő) statusbar-jára. Logikusan ez az X nevű libbe kerülne ugye. Igenám, de van olyan függvényemis ami beolvas egy png képet egy stringbe, s olyan is ami aztán e stringet kiírja a grafikus képernyőre, persze kép formájában. Meg olyan is van ami egy ilyen "képstringet" kiír egy (png) fájlba. Most ezek akkor az io libbe kerüljenek, vagy az X libbe (hiszen grafikus képernyőre rajzolnak ki) vagy legyen egy külön png lib? Utóbbi logikusabbnak tűnhet, de mindjárt másképp tűnik ha belegondolok, arra is van funkcióm hogy a grafikus ablak tartalmát elmentsem png képként. Ez most akkor X funkciónak van tekintve vagy png funkciónak?

Na befejezem, megyek aludni (egyelőre...). Köszi az eddigi segítséget! Bár mindenki ilyen rendes, lényegre törő és segítőkész volna mint te!

—Érdemes-e szerinted egy külön "shared" libet is kreálni, amiben a shared memory kezelésének függvényei vannak benne, vagy ez a core része legyen?

—Hova kerüljön a fork() funkció? ... Netán épp emiatt egyik se legyen a core része, de kerüljenek egyetlen közös libbe? Ha igen mi legyen annak a libnek a neve?

Nem tudom :) Ha a shared memory kezeles logikailag onallo egyseget alkot, akkor lehet ertelme kulon libraryt kesziteni. Ha kizarolag a fork()-al egyutt hasznalando, akkor mehet a ketto egy "process" vagy ilyesmi libbe gondolom, amiben a kulso processek kezelesevel kapcsolatos fuggvenyek vannak. Megindokolhato mindketto miert jo, vagy miert nem jo, vagy hogy miert keruljon a coreba.

Igenám, de van olyan függvényemis ami beolvas egy png képet egy stringbe

png file -> string: "image" lib, amiben a kepfajl kezelessel kapcsolatos fuggvenyek vannak? Vagy ha nem akarod annyira fragmentalni a libeket, akkor "io".

olyan is ami aztán e stringet kiírja a grafikus képernyőre, persze kép formájában

string -> kepernyo: "X" lib, ami a grafikus kepernyot kezeli. Es ennek keszitenek egy inverz fuggvenyt is, ami a "kepernyo -> string"-et intezi.

Meg olyan is van ami egy ilyen "képstringet" kiír egy (png) fájlba.

string -> png file: "image" lib (vagy legalabbis ugyan az, ami beolvas png fajlt)

arra is van funkcióm hogy a grafikus ablak tartalmát elmentsem png képként. Ez most akkor X funkciónak van tekintve vagy png funkciónak?

Mindkettonek, ezert lehet az "X" libben levo kepernyo -> string fuggvenyt hasznalnam hogy egy stringbe rakjam a kepernyo tartalmat, majd pedig az "image" libben levo string -> png file fuggvenyt, hogy kiirjam png fajlba. Ha mindenkepp egy fuggvennyel akarod elintezni, akkor ennek olyan helyen kell lennie, amelyik az "X" es "image" libre is tud hivatkozni.

Azt is. :) De itt nem erről van szó, hanem írod:

—Egy karakter első előfordulásának keresése a stringben.

A fenti linken két metódust látsz:
   https://doc.rust-lang.org/std/string/struct.String.html#method.find
   https://doc.rust-lang.org/std/string/struct.String.html#method.rfind

Vélhetőleg nem feleslegesen van kettő, így érdemes ilyesmire is gondolni.
Tehát nem a dupla kettőspont a lényeg esetedben, inkább a praktikus funkciók terén kapsz ötletet, továbbá egyúttal az elnevezéséhez is.

Szerkesztve: 2020. 11. 09., h - 02:12

Álljunk hozzá szó szerint értelmező 'spergautista módon, a célközönség kedvéért.  Tehát:

 

—string megfordítása helyben

—gnirts

 

—string első karaklerének elhagyása

—tring

 

—string utolsó karakterének elhagyása

—strin

Nem tudom mi az a sperg, autista pedig nem vagyok. Asperger-szindrómás (röviden Aspie) igen. Az azonban nem azonos az autizmussal. Egy Aspie el tudja látni magát, sőt többnyire kifejezetten zseni bizonyos speciális részterületeken. Egy autista, az nem. Szóval bár néhány tünet lehet hasonló, a két dolog teljesen más a lényegét illetően. A nátha se azonos a pestissel.

Ettől még a tring és a strin jó ötlet, amennyiben JÓPOFA. Nekem tetszik. Kétlem azonban, hogy úgy általában nagy tömegek tetszését megnyerné. A gnirts meg kifejezetten nehézkes is, soká tart felismerni mire utal, és még kimondani se könnyű, márpedig tapasztalatom szerint azok a kulcsszavak a könnyen memorizálhatóak, amik könnyen kiejthetők.

Böfff. Jöttem barátkozni.

Hivatásos pitiáner
neut @

Na és ezt épp azért írtam példának mert már majdnem így döntöttem hogy legyen ez a substring szimbóluma, amikor eszembe villant hogy Oh my God, megint mire készülök... jön majd a kritika hogy a nyelvem megtanulhatatlan meg minden...

offtopik: igazából az van, hogy programot írni könnyű, programot olvasni viszont esetenként baromi nehéz

Általánosságban abba az irányba mennék (bár valszeg ez pont ellentétes a te koncepcióddal), hogy inkább legyen bőbeszédű a nyelv hosszú, de kifejező függvénynevek, minthogy mindent bogarászni kelljen, ha valaki másnak el kell olvasnia a kódot. Nem hiszem hogy bármiféle észrevehető performance impact lenne, bár nyilván egy próbát megérhet.

Szerkesztve: 2020. 11. 09., h - 14:42

Tehát konkretice: mit javasoltok a következő funkciók neveinek: 

substring képzése

0x839DFFD6645AD372

string megfordítása helyben

0xE4B0E81F2EA3D3BC

string első karaklerének elhagyása

0xE7CB25C6F9045550

string utolsó karakterének elhagyása

0x1BD10A4AAD91A8B8

egy karakter hozzáfűzése a string végéhez.

0xB22197F6B2EB1933

dissect: stringből egy rész kihagyása.

0x481708026FEFFF92

Egy string beszúrása a string egy adott pozíciója ELÉ, illetve azon pozíció UTÁN.

0x911BEEF84EF37EBC

Annak vizsgálata, egy string tartalmaz-e egy másik stringet a belsejében

0x83CE344C155A6ABF

Egy karakter első előfordulásának keresése a stringben.

0x4E5AFB65AF730CB4

A string karaktereinek balra vagy jobbra léptetése (rotációja) .

0xB92EA51B4E29D8CF

A string karaktereinek kis- illetve nagybetűssé alakítása.

0xCCDE8E7BD241F745

A string feltöltése egy adott karakterrel.

0x5E078699FB20C9D8

String előállítása egy adott karakter n-számú ismétlésével.

0xF282DFEA63DFE603

A string balra-, jobbra-, illetve középre igazítása egy adott hosszúságú mezőben, a maradék közöket szóközzel feltöltve, szükség esetén a kilógó vég csonkolásával.

0x4E44B85DFAA4B383

A string balra igazítása az MC-ben szokásos módon, amikoris ha a string hosszabb mint a megadott mezőhossz, akkor az elejét és a végét látjuk, és középen van kihagyva a bele nem férő mennyiség, s ezt egy ~ karakter jelöli.

0x1A641BA6FB144DD0

A string elején levő whitespace karakterek lehagyása.

0x64D7B8F42391ADB1

A string végén levő whitespace karakterek lehagyása.

0xCAFED3774290D246

A string elején és végén levő whitespace karakterek lehagyása.

0x5FD4D4FA685A2A4F

A stringben levő összes whitespace karakter szóközre cserélése.

0x80F9F8F674809D7E

A stringben levő összes whitespace karakter lecserélése szóközre úgy, hogy az egymás utáni whitespace karakterek csoportja egyetlen szóközzel van helyettesítve.

0x918A0B86EBED3B4A

Annak vizsgálata hogy a string végén egy / jel van-e, s ha nem akkor kiegészíti e jellel a stringet.

0xED4879B9D445563B

Annak vizsgálata hogy a string végén egy újsor jel van-e, s ha nem akkor kiegészíti e jellel a stringet.

0x5629946BDC1A70E1

Annak vizsgálata, a string végén újsor karakter áll-e, s ha igen, akkor azt lehagyja.

0x0E1C3C90583CF2F9

Az összes C stílusú azaz // -el kezdődő vagy /* ... */ közti megjegyzés eltávolítása a stringből.

0x7C80E2B25D7D815F

File beolvasása a stringbe.

0xC3384558370DFAEB

A string stringtömbbé alakítása, úgy, hogy a stringtömb egy sorába az kerül amit újsor karakter zár le.

0xE252C933DC42ECFC

String kiiratása fájlba, UTF-8 formátumban.

0x173B627674EDF646

Egy karakter előfordulásainak száma a stringben.

0xED44DF6B21B1B98B

A string szavakra bontása. Azaz e művelet eredménye egy stringtömb lesz aminek minden eleme egy szó. Szó az amit whitespace karakterek határolnak (vagy a string legeleje vagy vége).

0x11FF4B5DD7953DBC

szélsőségesen idealista, fősodratú hozzászólás

Röhögni fogsz, de a megoldás a függvényeim bő 99 százalékában épp ez... „ott lenn a mélyben”. Vagy legalábbis valami nagyon hasonló. Épp csak ennél azért még én is felhasználóbarátabb szintaxist óhajtok. Az ilyen durvaságokat jobb elrejteni Felhasználó Őfelsége finnyás tekintete elől.

Van, olyan értelemben hogy halálnyugodtan meg lehet csinálni hogy egy kulcsszóban legyen akárhány emoji. Vagy horrible dictu CSAK azokból álljon. Írtam már, a kulcsszavak tetszőleges akármiket tartalmazhatnak ami benne van az Unicode táblában. Az egyetlen kikötés hogy nem lehet whitespőace, azaz semmi olyan aminek a kódja kisebb mint 33.

Nem értem azt a „klasszikust”. Megnéztem, de fogalmam sincs róla mi az a zagyvaság, mire céloz.

Azt meg szintén nem tudom, a Swift hogy jön ide. Meg se említettem. Nyilvánvaló, kevés az esély rá hogy bármi újat feltalálok a nyelvemben. Azaz amit az tud, simán tudjhatja a Swift vagy akármi más is. Na és? Az én célom csak annyi hogy legyen egy SAJÁT nyelvem, amit nyugodtan használhatok a regényeimben, s hasznos is NEKEM a napi kisebb programozási teendőimben.

A "klasszikus" egy matek vizsga feladatlapja, ahol a vizsgázó a megszokott "x, y, z" változó jelölések helyett ábrákat használt. A vizsgáztató nehezen értelmezte, de technikailag jó volt a megoldás, viszont azt mondta a diáknak, hogy ezt így többet ne.

Azt tudom, hogy te a saját nyelvedet akarod megvalósítani. Én meg szeretem a Swiftet, mert a szokásos Apple féle magas minőséget hordozza. Mivel a téma az emojik használata volt változónévként, így bemutattam, hogy nem lehetetlen megcsinálni, Swiftben pl. már lehet. 

Köszi a magyarázatot.

Oké, lehet a Swiftben emojikat használni. Oké, lehet az én nyelvemben is. DE MI ENNEK AZ ÉRTELME?!

Nekem eszem ágában se volt beépíteni e lehetőséget a nyelvembe DIREKT. Mindigis utáltam az emojikat...

Az hogy a nyelvem képes erre IS, egy „side-effect” vagy hogy is mondjam, annak a mellékes hozománya hogy bármilyen unicode karaktert lehet benne használni. De ezt nem az emojik kedvéért csináltam meg, hanem azért, hogy aki netán a saját anyanyelve ékezetes karaktereit is szerepeltetni akarja a változónevekben, az megtehesse.

Annak van értelme ugyanis, bár annak is csak akkor ha csak önmagának írja a programot, mert nemzetközi környezetben nyilván kerülendő az is.

Na de az emojik?! Az lenne aztán az igazi horror hogy olyat változónévbe...

Az emojik változónévként használatának tényleg nincs sok értelme (hacsaknem: https://hup.hu/node/171010), de pl. a Color Literalnak, Image Literalnak már annál több. Ekkor a szín hexa kódja helyett a színnek megfelelő téglalapot látsz, rákattintva előjön a colorpicker. Apróság, de nagyon kényelmes.

a Color Literalnak, Image Literalnak már annál több. Ekkor a szín hexa kódja helyett a színnek megfelelő téglalapot látsz, rákattintva előjön a colorpicker. 

Ez IDE feature, vagy a nyelv tudja valahogy? (Értsd: ha megnyitod a forrásfájlt egy random texteditorban, mi lesz a téglalap helyén?)

Megnéztem a linket, de nem igazán értem, ennek mi köze van a NYELVHEZ. Teljesen nyilvánvaló ugyanis, hogy ilyen feature csak grafikus környezetben megvalósítható. Egyáltalán, én hideglelést kapok az olyan micsodáktól ahol úgy kell programozni hogy ikonokat rángatunk a képernyőn, meg kattintgatunk stb, és majd valami program megírja HELYETTEM a tényleges kódot ennek alapján...

Próbáltam, de képtelen voltam megtanulni. Valószínűleg nem azért voltam képtelen mintha eleve hülye lennék hozzá, de annyira TASZÍTOTT az egész koncepció, annyira természetellenesnek éreztem (nyilván mert annak idején még kis gépeken „szocializálódtam”, nagyrészt gépi kódú környezetben) hogy teljesen idegen volt a gondolkodási patternjeimtől, utáltam, nem állt kézre, stb...

Eszemben sincs ilyesmit beleépíteni a nyelvembe. Az esetleg beleférhet hogy színstringeket szimbolikus nevekkel lássunk el. De nem az hogy KATTINTGASSUNK...

Annyit tennék hozzá, hogy szerintem mindenképpen szükséges a névterekre bontás, azaz ezek a függvények ne a globális névtérbe legyenek behányva, hanem mondjuk egy furor.String névtérbe. Aki használni akarja, az importálja, vagy írja ki a teljes nevét!

Ez azért fontos, mert ha nincsenek névterek, és később bővíted az alap dolgokat, akkor az könnyen inkompatibilitást okozhat.

Kemény meló a névterek tisztességes implementálása: főleg mikor parszoláskor fel kell oldani, hogy mi honnan jön, illetve editor segítségek nélkül kényelmetlen a használata is, de végsősoron nagyon megéri. Én enélkül már nem csinálnék programnyelvet ${CURRENT_YEAR}.

Hehehe, ez RÉG készen van... De annyira, hogy... hogy is mondjam... szóval ott fentebb láthatod a példaprogramjaimban, a kezdő soruk az hogy

###sysinclude standard.uh

Ez egy include utasítás nyilván. A main programba (bár nálam annak neve nem main hanem BigBoss) behúzza a standard.uh include fájlt.

DE CSAK ABBA:::

Azaz itt bizony az van hogy az összes, ÖSSZES függvénybe be kell includeolni amit az használ. Azért függvénybe, mert nálam minden függvény külön névtér. A névtér és a függvény fogalma nálam ugyanaz.

Ez szar ügynek tűnhet elsőre, hogy be kell includeolni mindegyikbe, másrészt viszont megvan az a nagy haszna, hogy így tényleg jelenthet ugyanaz a függvény vagy operátor tök más dolgot is a különböző függvényekben.

És persze azért az egyes függvények ettől még hivatkozhatnak egymásra bizonyos konvenciók betartásával, sőt, ez a lehetőség még a későbbiekben bővül majd a terveim szerint pár ficsőrrel.

Azt meg még nem is mondtam, a C nyelvvel ellentétben nálam a függvények épp emiatt nem a globális névtér részei, hanem matrjoskaszerűen egymásba lehet őket ágyazni... Hasonlóan mint a könyvtárrendszer.

Van mar valakinek cronban scriptje archive.org / archive.is snapshotolasra, vagy csinaljak egyet, hogy ne vesszen megint oda mindenki ertekes kommentje? :)

Készülget az új nyelvecském, egy csomó mindenre már a Periben írt szkripteket használom az éles rendszeremen... de akadnak még amiket a régebbi nyelvem, a Furor működtet.

Na most a baj az hogy belefutottam egy problemuszba. Akad pár Furor szkriptem amiben listafeldolgozó utasítások vannak. Ezek elég komplex valamik. És hát az az igazság hogy rájöttem, hogy úgy ahogy ezt megoldottam a Furorban, úgy nekem ez egyszerűen nem tetszik... Működnek hiba nélkül. De nem tetszik. Most várnom kell amíg ihletődésem támad, miként oldjam meg ezt a kérdéskört a Periben...

Szóval bocs meg medve, itt és most a morfondírozásnak vagyon az ő ideje, ezért nem blogolgatok perpillanat a témáról, holott tudom hogy tűkön sőt óriás lódarazsak fullánkjain ültök képletesen szólva a türelmetlenségtől...

De jó munkához idő kell ugye, hamar munka ritkán jó, lassan járj tovább élsz (érsz...) tehát most inkább becsomagolom a türelmetlenség repülőszőnyegét a várakozás erős ládájába mely a megfontoltság lakatjával van lezárva, amit csak az idő érlelte bölcsesség kulcsa képes kinyitni...

Szerkesztve: 2020. 11. 22., v - 01:52

Nos, a nyelvecském már egész szépen kiforrta magát. A főbb változások amik az eltelt időben történtek:

—A fork() és a shared memory kezelése bekerült a core-ba. Ennek az az oka, hogy úgy döntöttem, a stringtömbök built-in módon támogatva lesznek, mert nekem rendkívül gyakran van szükségem rájuk, márpedig a stringtömbök nálam nagyon gyakran úgy vannak „előállítva”, hogy a shared memory területen helyezkednek el. Célszerű volt tehát megcsinálnom, hogy legyen támogatás a „közönséges” stringtömbökre is, és a shared memoryban elhelyezkedőkre is. Ha ez a core része, persze hogy a fork is oda kell kerüljön, minthogy a shared memory a legtöbbször úgyis az interprocess kommunikáció célját szolgálja!

Egy másik indok, hogy sikerült kiihlenem magamból egy olyan szintaxist erre az egészre, ami nekem nagyon tetszik mert logikusnak tűnik, a feldolgozása is gyors, de nagyon macerás lett volna megcsinálni akkor, ha nem a core része.

Közben megcsináltam (megint) a Conway féle Life játékot. Ezzel a stringtömb kezeléssel. Szépen működött... Egészen addig amíg háromszázvalahány nemzedéket ki nem rajzolt. Akkor ugyanis segfault...

Persze már gyakorlott vagyok ilyesmiben, azonnal arra gyanakodtam, a stack-kezelésben lesz a hiba. Na de mi, a stackom eddig kiválóan szerepelt mindenütt... Végül kiderült, egy teljesen pitiáner, ótvar kis szutyok rutinban a hiba. Abban, ami várakozik két generáció közt, az usleep() függvénnyel. Ennek paramétere persze a stackban van átadva. Na és amikor ezt megírtam fáradtan tegnap, tévedésből ezt írtam a végére:

STACK0.g--;

ehelyett:

STACKP--;

Vagyis nem a stackpointert csökkentettem eggyel hogy törölje a már szükségtelen paramétert, hanem a stack legfelső elemének értékét csökkentettem... nagy különbség ugye, s persze hogy emiatt betelt a stack...

(A STACK0 és a STACKP egy-egy #define direktíva nálam. Ezt csak az érthetőség kedvéért írtam le).

Hát efféle kalandjaim vannak...

A másik amiért nekiestem ennek a stringtömbös hóbelevancnak, az az, hogy ahogy most átírtam, kiválóan továbbfejleszthető egy komplett listakezelő alrendszerré, márpedig fentebbi (régi) hozzászólásomban azon elmélkedtem hogy azt a részt át kell gondolnom mert a régi megoldás nem tetszik szívem szottyának. Ez a mostani út azonban ígéretesnek tűnik. Debütálni az új módszer abban a feladatban fog, amikoris a közismert vidir programot írom meg a magam peri nyelvén. Oda nagyon jól jönnek majd a listafeldolgozó ficsőrök.

Remélem tudod, hogy ez nemcsak humoros nem volt de magadat minősíted vele.

Még meg is érteném hogy ilyet írsz, ha állandóan trollkodtam volna veled. De ilyet sose tettem, te járkálsz állandóan a topikjaimba trollkodni. És ezek után még van bőr az ocsmány pofádon neked kívánni az én halálomat?

Ez annyira aljas és genyó dolog, hogy szavam sincs rá.

Igen, ezzel önmagadat minősítetted. LE. De nagyon ám.

Akkor elnézésedet kérem amiért ilyen csúnyaságot tételeztem fel rólad! Őszintén! Bocs!

Ellenben magyarázd el kérlek, hogyan kell érteni a "gyászjelentés" szót egy programnyelvvel kapcsolatban, mert neked bevallom (de tartsd titokban hogy más meg ne tudja!) hogy fogalmam sincs hogyan kell ezt értsem.

A "Deprecation announcement" igen pontos forditas.

Upu gyaszjelentese: "Upu mar nincs, mar csak Furor van"

Aztan a Furornak is lett "gyaszjelentese" - kozolted, hogy nem fejleszted tovabb, helyette egy uj nyelven dolgozol.

Most az "uj nyelv gyaszjelentesere varas" gunyolodas az elozo ketto rovid eleten: 1 useruk volt, es 1 fejlesztojuk, majd a "gyaszjelentes" utan 0 user es 0 fejleszto lett (= halott). Es a korabbi "deprecation"-okbol es userszamnovelesi szokasokbol "varhato" egy ujabb "gyaszjelentes" ennek az ujabb nyelvnek is.

Ezt szerette volna kozolni a kollega.

Köszi szépen a magyarázatot!

De a Peri esetén nem lesz ilyen „gyászjelentés”. Azért nem, mert maga a „Peri” név annyira tetszik. Könnyű kiejteni, angolul kimondva is majdnem pontosan úgy hangzik mint magyarul, rövid, a jelentése is nagyon pozitív...

Szóval, maximum olyasmi képzelhető el, mint a Pythonnál: hogy jön egy új verzió, ami bár nagyon hasonló az előzőhöz, de nem kompatibilis vele mégse, apró nüanszok miatt.

Igazság szerint ez már most is így van, amennyiben a Peri LÉNYEGÉBEN nem más mint maga a Furor, mert bár nem kompatibilis vele, de NAGYON könnyű átírni Furor programokat Perire.

A Furor esetén tehát még a „gyászjelentés” szó használatának jogossága is vitatható szerintem. Akkor jogos, ha jogosnak érzitek ezt a régi python nyelvre is vonatkoztatni, azóta, hogy van újabb verzió ami a régivel nem kompatibilis.

A kutya nem fogja használni, a kutyát nem érdekli a noname nyelved, szóval kurvamindegy mi a neve és miért.  A lényeg, hogy jól érzed magad közben.

A fenti kommentemet kérem majd forrásmegjelöléssel használják fel a jövő IT történészei, amikor a Peri nyelv születésének körülményeiről írnak a Peri powered HKnix hajtotta gépükön.

Hivatásos pitiáner
neut @

Meghalt a Furor. Éljen a Peri!

„Élesítettem” a Perit ugyanis. Persze ez egy folyamatos folyamat volt, ha szabad ilyen szóismétlésesen kifejezni magamat. (de szabad, mert önmagam megengedte önnönmagamnak). Lényeg az hogy mostanra már minden szkriptet lecseréltem Furorról Perire, ami a gépemet hajtja.

Mondhatni tehát hogy készen van a Drágaszág, elkészült hát a Nagy Mű, igen, a gép dolgozik, s az Alkotó pihen...

Vagy mégsem. Mert egy ótvar-nagy hiányossága mégis vagyon nekije: Egy árva sor sincs kész a dokumentációjából...

Hát, ezt még meg kell írnom, mert ugye a WC-ülőkén csücsülve se mondhatod hogy „készen vagy”, amíg a papírmunkával is nem végeztél...