Literatura dot. projektowania interpreterów/kompilatorów języków programowania

[FlyingDutch]

Cześć,

czy ktoś mógłby polecić jakieś pozycje literatury dotyczące projektowania interpreterów i kompilatorów języków programowania (wiem ,że to  dwa różne tematy) . Chodzi mi zarówno o pozycje dla początkujących, jak i zawierające więcej szczegółów. Interesują mnie także pozycje dot. wykorzystania parserów/generatorów składni takich jak  Bison czy Yacc do tworzenia prostych języków skryptowych.. Jestem także zainteresowany literaturą (lub artykułami w sieci) opisującymi wykorzystanie funkcyjnych języków programowania takich jak Lisp, Clojure czy Scala (lub nawet Python) do tworzenia własnych prostych języków skryptowych (interpreterów). Interesuje mnie literatura polsko lub angielsko języczna.

Pozdrawiam

[Elvis]

"Kompilatory. Reguły, metody i narzędzia" Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman

Powiedziałbym, że to klasyka tematu

Angielska wersja jest dostępna w pdf: http://www.informatik.uni-bremen.de/agbkb/lehre/ccfl/Material/ALSUdragonbook.pdf

[marek1707]

Dla mnie to "Konstrukcja kompilatorów" Waite/Goods i "Metody kompilacji" Hopgood'a. Obie mam, obie bardzo dobre, obie kiedyś wydane po polsku.

[ethanak]

też się uczyłem z "konstrukcji kompilatorów" - pomijając fatalne tłumaczenie (znając angielski można było dojść do tego o co autorowi chodziło) naprawdę świetna pozycja.

poza tym jeśli gdzieś dopadniesz "projektowanie niezawodnego oprogramowania" (bodajże Myersa ale nie jestem pewien) to warto poczytać jak kryminał do poduszki.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[deshipu]

2 godziny temu, FlyingDutch napisał:

Jestem także zainteresowany literaturą (lub artykułami w sieci) opisującymi wykorzystanie funkcyjnych języków programowania takich jak Lisp, Clojure czy Scala (lub nawet Python) do tworzenia własnych prostych języków skryptowych (interpreterów).

Obczaj to: https://rpython.readthedocs.io

[ethanak]

a słyszałeś może, że istnieją inne języki oprócz Pythona? Polecam zapoznanie się z Snobol4 czy Iconem.

[deshipu]

5 godzin temu, ethanak napisał:

a słyszałeś może, że istnieją inne języki oprócz Pythona? Polecam zapoznanie się z Snobol4 czy Iconem.

A wystarczyło tylko kliknąć i przeczytać pierwsze zdanie. Ale nie, to byłby za duży wysiłek, lepiej zareagować wścieklizną na każde wystąpienia słowa "python". To się leczy.

Tak, słyszałem, że istnieją inne języki. Na przykład rpython jest innym językiem niż python, a także wiele języków dla których interpretery są napisane w rpythonie jest innymi językami niż python, na przykład: squeak, lisp, monte, tulip, racket, lever, prolog, ruby, r, php, scheme, javascript, haskell, io, quoppa.

Więc wzajemnie polecam zapoznanie się, szczególnie przed wysłaniem takich komentarzy.

Edytowano Styczeń 10, 2019 przez deshipu

[marek1707]

Eee tam, parafrazując znany rysunek Mleczki (ten z ajfonem): Python Srython 😉 Nie ma to jak nostalgia za minionymi czasami i wiara w to, że podejmowało się wyłącznie dobre wybory. Ja pisałem moje interpretery (BASICa) w asemblerach różnych procesorów i działały jak Bryka Młodego Wieśniaka po wyjeździe z dziupli. Można? Można. 🙂 Wtedy nie dawało się inaczej (o kompilatorze C na 8051 tylko słyszałem, że podobno gdzieś istnieje, a na 8080 miałem PL/M) a dziś.. już by mi się nie chciało.

A próbował ktoś pisać w Brainfuck'u? Ja po zrobieniu konwersji bin->ASCII odpuściłem, ale wciąż chodzi mi po głowie "zaembedowanie" tego mikrośrodowiska w jakimś większym programie. Nie zżera wielu zasobów nawet małego procesorka (zamyka się w jednym prostym switchu) a znakomicie.. zaciemnia algorytm. No i ile z tego radochy? 🙂 Swoją drogą istnieje stwierdzenie, że każdy wystarczająco nietrywialny program zawiera w sobie jakiś skrypt i jego interpreter. To nie musi być od razu zrozumiały dla człowieka program/tekst ASCII, a raczej jakieś sterowanie np. zawartością tablicy (vide: systemy organizacji menu - to też interpretery), ale równie dobrze Lua, która np. w grach zagnieździła się już na dobre.

[ethanak]

Kto to kiedyś powiedział, że jeśli w danym języku występuje dodawanie i skok warunkowy, to da się w nim napisać kompilator?

 

[deshipu]

1 godzinę temu, marek1707 napisał:

Swoją drogą istnieje stwierdzenie, że każdy wystarczająco nietrywialny program zawiera w sobie jakiś skrypt i jego interpreter.

Masz na myśli dziesiątą zasadę Greenspuna?

Jasne, teoretycznie "da się" we wszystkim, co jest turing-complete (a że mamy turing tarpit, to prawie wszystko jest turing-complete), ale wydaje mi się, że autor wątku tym razem próbuje rozwiązać bardzo konkretny praktyczny problem i szuka nie teoretycznych rozważań czy zabawnych trików, ale solidnych narzędzi, a rpython właśnie takim solidnym narzędziem jest.

[FlyingDutch]

Cześć,

dziękuję wszystkim za odpowiedzi. Książkę polecaną przez Elvisa ściągnąłem i jest naprawdę fajna. Literaturę polecaną przez Marka i ethanak'a postaram się gdzieś wypożyczyć.

A zacznę od poznania rozwiązania przedstawionego przez deshipu, bo właśnie czegoś podobnego poszukiwałem. Chciałbym stworzyć minimalistyczny język skryptowy, który mógłbym łatwo wbudować w projektowaną aplikację. Na początku myślałem właśnie o języku Lua bo dobrze się integruje z aplikacjami pisanymi w języku C, ale stwierdziłem, że tak naprawdę potrzebuję dużo mniej niż oferuje Lua, stąd moje zainteresowanie powyższym tematem. Niestety dzisiejsze tempo życia powoduje, że niektórym tematom ni jesteśmy w stanie poświęcić tyle czasu ile byśmy chcieli i co najgorsze ile trzeba by poświęcić, aby temat naprawdę poznać.

Pozdrawiam

 

[deshipu]

Podejrzewam, że z Lua jednak będzie szybciej, nawet jeśli robi ona więcej niż potrzebujesz.

[FlyingDutch]

Cześć deshipu,

właściwie to mógłbym użyć wbudowanego w aplikację interpretera Perl'a bo to robiłem już kilka razy (i Perla znam lepiej niż Lua), lub Lua jak mówisz ale naprawdę potrzebuję dużo mniej i chciałbym mieć coś naprawdę "małego" nad którym miałbym pełną kontrolę. Decyzji jeszcze nie podjąłem.

Pozdrawiam