Új szkript nyelv illetve interpreter típusú nyelv írása

Szkriptek: Python, Perl, Bash, ...

Igazából nem vagyok biztos benne, jó alfórumba raktam-e, ugyanis az új szkriptnyelv C/C++ -ban lenne megírva.

Tehát: a téma rém egyszerű. Ne kezdjen senki arra biztatni hogy minek kellene megírni egy szkriptnyelvet, amikor van sok. Hogy minek? Pld hobbiból.

Egyelőre momentán különben csak annyi érdekelne, hogy van-e valakinek tudomása olyan, Interneten elérhető MAGYAR NYELVŰ szakirodalomról, ami olyasmit taglal, hogy miként írjunk meg egy alapvetően interpreter típusú programnyelvet. Hozzátenném, e téren vannak már bizonyos tapasztalataim, meg ötleteim is, de pusztán szórakozásból szívesen olvasnék ilyesmiről. De csak magyarul. Angolul nem tudok úgy, hogy azon a nyelven olvasva az nekem szórakozás legyen.

Lényegében a legfontosabb rész ezen belül is az lenne, hogy mások miként oldották meg a képletkiértékelő rutint (azt sejtem ám, hogy rekurzív függvénnyel), illetve miféle módszereket alkalmaztak az ugróutasításoknál, hogy az gyors legyen.

Ismétlem, mindezt mind meg tudom oldani magam is ha nagyon akarom, csak érdekelnének mások tapasztalatai is, mert ha megoldok is valamit, nem biztos hogy az optimális lesz.

Tehát, csak néhány linket kérnék, aki tud ilyenről.

  • 2279 megtekintés

( Aadaam v | 2008. 02. 02., szo – 21:51 )

yacc, bison, lex ... (utility-k)

Bach Ivan: Formalis Nyelvek (konyv)

Infix nyelvek, postfix nyelvek, kornyezetfuggetlen nyelvek, veremautomata, ll, lr (kifejezesek)

Nem linkek, de csak segit

( phaul | 2008. 02. 02., szo – 22:03 )

Csornyei Zoltan: Forditoprogramok I/II.
Mit ertesz a kepletkiertekelo rutinon? Aritmetikai kifejezest? Az eleg egyszeru. (lasd lengyel forma)
PS.
Meg ne sertodj sztem alulbecsulod a temat. Kb. felevnyi fordprog elmelet tanulas utan lehet ennek nekikezdeni...
==
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.

( Kormoraan | 2008. 02. 02., szo – 22:03 )

Hm... engem érdekelne a projekted.
Sajnos nekem nincs időm ilyesmivel foglalkozni jelenleg, de mindig nagyon érdekelt az ügy.
Kódból interpretálva, vagy virtuális gépre fordítva képzelted el?

Igazából azon töröm a fejemet, hogy... hát, lényegében amin az én szép és okos fejecskémet :-)) töröm az az, hogy kéne egy komplett virtuális gépet emulálni. De ez nem egy PC emulátor lenne, hanem egy elképzelt gép, ami még nincs, eképp a saját gépi kódú utasításkészletét is mi határoznánk meg. No most efféle elemi utasítások megírása nem egy nagy szám. Az érdekes ebben az lenne, hogy úgy írnánk meg, hogy minden egyes rutin külön-külön egy efféle emulált virtuális komputerben futna (látszatra), azaz azt higgye ő a "világon" az egyetlen rutin. Mindig ha kommunikálni akar valami más rutinnal, akkor annak a "nevét" küldi el - plusz a rutinnak szóló adatokat elteszi egy memóriaterületre ami a saját memóriaterületének egy része, s ennek a címét is elküldi - egy belső szervernek, ami továbbítja azt a hívott rutinnak. De ezt a hívó lényegében úgy érzi, mintha egy másik számítógéppel kommunikálna. Minden memóriaterület csakis olvasható MÁS programok számára, akik nem tulajdonosai az adott memóriaterületnek. Ebből következik, hogy ha ez megvalósul ténylegesen is lehet osztott rendszereket készíteni, hogy egy sok összetevőből álló nagy progi rutinjai valóságosan is külön gépeken fusanak, mert valóban mindegy nekik, hogy hol futnak - minden rutin csak magáért felel, és nem ránthatja magával összeomláskor az egész rendszert. Természetesen egy külön rutin az is, ami a képernyőt kezeli, meg az is ami a felhasználóval kommunikál a billentyűzeten át, stb. Voltaképp emiatt a rutinok azt sem tudják mi az a képernyő, ők kilöknék egy adatterületre az adatokat, és közölnék hogy most ez kész, el kéne vinni onnan - az outputkezelő dolga volna hogy eldöntse, ezt most épp grafikus képernyőre írja vagy konzolra vagy küldi interneten vagy fájlba írja vagy akármi más.

No most ehhez gondoltam írni első megközelítésben egy primitív kis szkriptnyelvet, mintegy a "gépi kódja" helyett, tesztelési célra. Mármint hogy a virtuális komputert teszteljem majd vele. Ha maga a koncepció jól működik, természetesen kell majd rá írni "normál" C fordítót, meg minden mást.

Mint a leírásból kitűnik, e "project" még erősen pre-alfa, annyira, hogy inkább csak tervezési szinten van még. Maga a programnyelv semmi esetre sem lenne bonyolultabb mint egy BASIC, és nem óhajtanék semmi fordítási dolgot belevenni: futásidőben értelmeződnének ki a sorok (amik a program futása alatt a program által akár módosíthatóak is lennének, bár nemigen tudom elképzelni, ennek mikor lenne értelme...) és minden sor 1 utasítás lenne.
Képletkiértékelőn természetesen aritmetikai kifejezés kiértékelését értem. Annyit mindenképp beleveszek majd, hogy lesznek külön bináris és hexa számok is, a bináris számokat a % prefix jelöli majd, a hexákat a $ prefix. (Utóbbi nálam C-64 korszakból származó emlék, és különben is utálom a C nyelv 0x jelölését, mert 2 karakter 1 helyett).

-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Ebben az esetben amiről beszéltem, nehezen lehet elválasztani egymástól az operációs rendszert és a virtuális gépet.

Ha egy még nem létező gépet emulálunk, akkor annak nyilván saját - és még nem létező - operációs rendszere van, amit szintén emulálnunk kell, akár akarjuk, akár nem.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Nekem ez kicsit flame szagúnak tűnt... Bocs ha nem az.
De ha akarja, csinálja csak! Kis ötletekből lesznek a nagy dolgok. Lehet hogy ez is egy lesz a sok megrekedt, soha el nem készült dolog közt... De nem így kell nekiindulni, mert akkor tényleg soha nem lesz belőle semmi.
--
Discover It - Have a lot of fun!

Mindenképpen nekikezdek. Tekintettel rá, hogy irtó kevés a szabadidőm, plusz fő életcélom és hobbim nem a számítástechnika hanem regények írása, így biztosan lassan halad majd, de nincs ezzel semmi gond, mert egyelőre úgyis csak hobbi. E topikot csak azon célra nyitottam, hogy néhány linket kérjek esetleg létező magyar leírásokra. Ha nincs ilyen hát nincs, semmi gond vele.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

"kéne egy komplett virtuális gépet emulálni (...) Mindig ha kommunikálni akar valami más rutinnal, akkor annak a "nevét" küldi el - plusz a rutinnak szóló adatokat elteszi egy memóriaterületre ami a saját memóriaterületének egy része, s ennek a címét is elküldi - egy belső szervernek, ami továbbítja azt a hívott rutinnak. De ezt a hívó lényegében úgy érzi, mintha egy másik számítógéppel kommunikálna (...) lehet osztott rendszereket készíteni, hogy egy sok összetevőből álló nagy progi rutinjai valóságosan is külön gépeken fusanak, mert valóban mindegy nekik, hogy hol futnak - minden rutin csak magáért felel, és nem ránthatja magával összeomláskor az egész rendszert"

Ezt (illetve ennek superset-jet) mar megvalositottak, o (pl.) az erlang).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Hajnali fél-szendergésemben eszembe jutott a szkriptnyelved, és arra a megállapításra jutottam, hogy a képletkiértékelő rutint talán nem rekurzív függvénnyel oldanám meg, hanem egy verembe tenném le a részeredményeket és az elvégzendő művelet kódját.

Hasonlóképpen a blokk-képző utasításokat is (if, while) verembe pakolásznám, hiszen a rekurzív függvények csak körülményesen tudnák kezelni a többszörösen beágyazott return, contunue, break utasításokat, hogy a try-ról és a goto-ról ne is beszéljünk.

Ami az ugrási címkéket illeti, (ha jól értelmeztem erről írtál) úgy lehetne gyorsítani, hogy névvel és hivatkozással táblázatba rendezed, éspedig a könnyebb keresés érdekében eleve ABC sorrendbe.

Parancsnyelvet én is terveztem már, de sosem álltam neki leprogramozni, nem volt időm ilyesmivel foglalkozni sajna, de a tervezéskor megszületett ötleteim is tanulságosak voltak. Számos jó elgondolásomat tudtam később is felhasználni.

Ami a virtuális gépedet illeti, legalább megvan a mai töprengenivalóm :)

( apal v | 2008. 02. 02., szo – 22:28 )

PSN. Azaz a bevitt kifejezest (kepletet) elso lepesben atalakitod lengyel kodda' (polish suffix notation), majd a lengyel kodot:
- alakitod tovabb (egyszerusited, optimalizalod, ha ugy hozza a szukseg, lederivalod) es/vagy
- ertekeled ki es/vagy
- alakitod vissza emberi fogyasztasra alkalmas formara.
Sajat fejlesztesu bizbaszoknal ez a megkozelites bevalt, hogy a felsobbszintu reszeket (utasitasok, elagazasok, fuggvenyek, ...) "kezzel", klasszikus eszkozokkel (egyszeru verem, rekurziv hivasok) dolgozza fel az adott program, a melyebben levo lepeseket (konkret kifejezesek kiertekelese) pedig PSN-ne' alakitja, majd azt tovabb. Van ehhez (marmint a PSN-hez) egy kis api is, ha erdekel el tudom kuldeni (de a doksija egyreszt hianyos, masreszt angol).

( begyu v | 2008. 02. 03., v – 11:55 )

Ajánlom figyelmedbe a "hoc" nyelvet!
Ez a Brian W.Kernighan, Rob Pike: The UNIX Programming Environment (Műszaki ISBN 963-10-7452-8) című UNIX könyv mellékletében szereplő példaprogram, ami több lépésben mutatja be az interpreter fejlesztését. A lex/yacc párosra épül és mivel csak a legfontosabb vezérlő utasítások, kifejezés-kiértékelés, matematikai függvények stb. megvalósítását tűzi ki céljául, így nagyon jó alap egy új interpreterhez.
Kapcsolódó linkek:
http://en.wikipedia.org/wiki/Hoc_%28programming_language%29
http://nadav.harel.org.il/homepage/hoc/
UHU csomag:
http://begyu.uw.hu/dev/hoc_9.1.2-1_i386.uhu