Számos olyan nyílt forráskódú vizuális programozási eszközt találtam, mint a Blockly és a barátok, valamint a Githubban tárolt egyéb projekteket, de nem találtam olyanokat, amelyek közvetlenül működnek az absztrakt szintaxisfa.
Miért van ez így?
I “m kérdezem, mert ha egyszer rájöttem, hogy minden fordítónak van egy fordítási folyamata, ahol a forráskódot AST-ként elemzi, nyilvánvaló volt számomra, hogy néhány vizuális programozási eszköz kihasználhatja ezt, hogy a programozónak módot adjon a Az AST közvetlenül vizuális módon, valamint az oda-vissza fordítás a forrástól a csomópont-grafikonig, majd vissza a forráshoz, ha szükséges.
Például azt gondolhatnánk, hogy a JavaScript AST Visualizer egy tényleges JavaSript vizuális programozó eszközhöz nincs túl nagy különbség.
Tehát , mit hiányolok?
Megjegyzések
- Az AST-k nagyon részletesek, és nem túl kényelmesek a programozáshoz. Fordítóknak tervezték, nem programozóknak.
- hu.wikipedia.org/wiki/Structure_editor
- Mit csináljon úgy érted, hogy ” közvetlenül az absztrakt szintaxisfával dolgozol “? Vélhetően az összes blokk alapú eszköz, például a Blockly, szerkeszti az AST-t: fészkeléssel (vagy halmozással jelölik az éleket, ha inkább így látja), és a felhasználó a fát szerkesztheti (mondjuk) húzással.
- Ez ‘ nagy kérdés, sokan, akik szeretjük a fordítókat. Szerintem a rövid válasz az, hogy ha ezt megtehetné és felhasználóbaráttá tehetné, akkor az emberek használnák. Az egyetlen probléma az, hogy ‘ nagy ” ha “.
- Megvizsgálta a Lisp elemeket? ” [Ez ‘ s] nem annyira, hogy a Lisp-nek furcsa szintaxisa lenne, mint hogy Lisp-nek nincs szintaxisa. Olyan programokat írsz az elemző fákba, amelyek a fordítóban jönnek létre, amikor más nyelveket elemeznek. De ezek az elemző fák teljesen hozzáférhetők a programjai számára. Írhat programokat, amelyek manipulálják őket. ”
Válasz
Ezen eszközök közül sok közvetlenül az absztrakt szintaxis fával dolgozik (vagy inkább egy közvetlen -egyik vizualizációja). Ide tartozik a Blockly, amelyet láttál, és a többi blokk alapú nyelv és szerkesztő is ( Scratch , Ceruzakód / Csepp , Snap! , GP , Csempézett kegyelem és így tovább).
Ezek a rendszerek nem ” hagyományos csúcs és él gráf ábrázolást mutatnak, másutt kifejtett okokból (tér és interakciós nehézségek), de közvetlenül egy fát képviselnek. Az egyik csomópont vagy blokk egy másik gyermeke, ha közvetlenül, fizikailag benne van a szülőben.
Ezen rendszerek egyikét felépítettem ( Csempézett kegyelem , papír , papír ). Biztosíthatom Önöket, hogy nagyon is közvetlenül az AST-vel dolgozik: amit a képernyőn látunk, az a szintaxisfa pontos ábrázolása, beágyazott DOM elemekként (tehát egy fa!).
Ez egyes kódok AST-je. A gyökér egy metódus csomópont “for … do”. Ennek a csomópontnak van néhány gyermeke, kezdve a “_ .. _” -val, amelynek önmagában két gyermeke van, egy “1” és egy “10” csomópont. A képernyőn pontosan az jelenik meg, amit a fordító háttérprogramja köp a folyamat közepén – ez alapvetően működik a rendszerben.
Ha úgy tetszik, úgy gondolhat rá, mint egy standard fa elrendezésre. úgy, hogy az élek kifelé mutatnak a képernyőn (és az előttük lévő blokk el van zárva), de a fészkelés ugyanolyan érvényes módja egy fa megjelenítésének, mint egy csúcsdiagram.
Ez “meg is fogja tenni” a körutazás a forrástól a csomópont-grafikonig, majd vissza a forrásig, ha szükséges “. Valójában láthatja, hogy ez megtörténik, amikor az alján található„ Kódnézet “gombra kattint. Ha módosítja a szöveget, akkor” újra elemzi és az eredményül kapott fát visszaállítja, hogy újra szerkeszthesse, és ha módosítja a blokkokat, ugyanez történik a forrással is.
A Ceruzakód lényegében ugyanazt csinálja, jobb felület . Az általa használt blokkok a CoffeeScript AST grafikus nézete.Tehát a többi blokk- vagy csempealapú rendszer is, bár némelyikük nem teszi annyira egyértelművé a fészkelési szempontot a vizuális ábrázolásban, és sokaknak nincs tényleges szövegnyelve a hátuk mögött, ezért ” a szintaxisfa “kissé illuzív lehet, de az elv megvan.
Amit tehát hiányolsz, az az, hogy ezek a rendszerek valóban közvetlenül működnek a absztrakt szintaxisfa. Amit lát és manipulál, az egy fa helytakarékos megjelenítése, sok esetben szó szerint az AST, amelyet egy fordító vagy elemző produkál.
Válasz
Legalább két ok:
-
Mivel a forráskód sokkal tömörebb reprezentáció. AST elrendezése grafikonként sokkal több vizuális ingatlant foglalna el.
A programozók a lehető legtöbb kontextusban részesülnek – azaz ha egyszerre annyi kód van a képernyőn, a kontextus segít jobban kezelni őket. bonyolultság. (Ez az egyik oka annak, hogy sokan haladnak az ammers ezeket az őrült kis betűtípusokat és a hatalmas 30 “képernyőket használja.)
Ha megpróbálnánk az AST-t grafikonként vagy faként megjeleníteni, akkor az a kódmennyiség, amelyet egyetlen képernyőn elférne, sokkal kevesebb lenne mint amikor forráskódként ábrázolják. Ez óriási veszteséget jelent a fejlesztői termelékenység szempontjából.
-
Az AST-k a fordító programozására szolgálnak, nem a programozók könnyű megértésére. Ha elkészít egy meglévő AST-ábrázolást, és vizuálisan megjeleníti, valószínűleg nehezebb lenne megértenie a fejlesztőknek, mert az AST-ket nem úgy tervezték, hogy a fejlesztők könnyen megtanulhassák őket.
Ezzel szemben a forráskód általában
t úgy fejlesztették ki, hogy olvasható / érthető legyen a fejlesztők számára; ez általában a forráskód kritikus tervezési kritériuma, az AST-k esetében azonban nem. Az AST-ket csak a fordító íróinak kell megérteniük, a mindennapi fejlesztőknek nem. És mindenesetre az AST nyelv lenne egy második nyelv, amelyet a fejlesztőknek meg kell tanulniuk, a forrásnyelvi nyelv mellett. Nem győzelem.
További lehetséges okokból lásd még: https://softwareengineering.stackexchange.com/q/119463/34181 .
Megjegyzések
- ” Ezzel szemben a forráskódot úgy tervezték, hogy olvasható / érthető legyen a fejlesztők számára ” – ellenpélda: a legtöbb esolang, Perl, Lisp
- ” Becaus az e forráskód sokkal tömörebb reprezentáció. “; ” az AST nyelv egy második nyelv lenne, amelyet a fejlesztőknek meg kell tanulniuk, a ” forrásnyelven kívül – ezek a minden vizuális PL, de nem segít megmagyarázni a különbséget, ami az OP-t érinti.
- ” (Ez ‘ az egyik oka annak, hogy sok programozó használja ezeket az őrült kis betűtípusokat és hatalmas 30 ” képernyőt.) ” – ha szükséged van egy nagy seggű képernyőre a megfelelő kontextus megtekintéséhez, talán ‘ újra spagetti-kódolsz? 😉
- @Raphael Talán, de ‘ kevesebb erőfeszítést tesz rá, hogy pénzt dobjon rá, mint visszafogni!
- @JanDvorak, .. A .LISP egy ellenpélda, mert az AST az a nyelv – ami megadja neki kifejező erejét; a másik LISP kódot újrafordító LISP kód írása ugyanolyan egyszerű, mint a szabványos LISP adatstruktúrákat módosító kód írása … amelyek pontosan azok, amelyekbe a LISP kód be van írva . ‘ oka annak, hogy ‘ s több mint fél évszázadig tartott – a család ‘ A design ritkán kifejező. A Go-nak aszinkron kiterjesztéseit mélyen be kellett vezetnie a nyelvbe és a futásidejébe; a Clojure esetében ez ‘ csak egy könyvtár. Lásd még: Az átlagok legyőzése .
Válasz
A fordítók tipikus AST-je meglehetősen összetett és részletes. Az irányított grafikonábrázolás gyorsan elég nehezen követhetővé válik. De a CS-nek két nagy területe van, ahol az AST-ket használják.
- A Lisp nyelveket valójában AST néven írják. A program forráskódja listaként van felírva, és közvetlenül a fordító és / vagy tolmács használja (attól függően, hogy melyik változatot használják). Az UML és számos vizuális tartományspecifikus nyelv olyan grafikus jelöléseket használ, amelyek hatékony absztrakt szintaxis grafikonokat (ASG) jelentenek az absztrakció magasabb szintjén, mint a tipikus általános célú AST nyelv.