Am găsit mai multe instrumente de programare vizuală open source precum Blockly and friends și alte proiecte găzduite la Github, dar nu am putut găsi niciunul care să funcționeze direct cu arborele abstract de sintaxă.
De ce este asta?
I „m întrebând pentru că odată ce am descoperit că fiecare compilator de acolo are o fază în procesul de compilare în care analizează codul sursă la un AST, a fost evident pentru mine că unele instrumente vizuale de programare ar putea profita de acest lucru pentru a oferi programatorului modalități de a edita AST direct într-un mod vizual și, de asemenea, pentru a face călătoria dus-întors de la sursă la nod-grafic și apoi înapoi din nou la sursă atunci când este necesar.
De exemplu, s-ar putea crede că din JavaScript AST Visualizer la un instrument de programare vizual JavaSript real nu există prea multă diferență.
, ce îmi lipsește?
Comentarii
- AST-urile sunt foarte detaliate și nu sunt foarte convenabile pentru programare. Au fost concepute pentru compilatoare, nu pentru programatori.
- en.wikipedia.org/wiki/Structure_editor
- Ce fac vrei să spui prin ” să lucrezi direct cu arborele de sintaxă abstract „? Probabil că toate instrumentele bazate pe blocuri, cum ar fi Blockly, editează AST: ele reprezintă marginile prin cuibărire (sau stivuire, dacă preferați să o vedeți așa), iar utilizatorul poate edita arborele prin (să zicem) prin glisare și fixare.
- Este ‘ o întrebare excelentă pe care am avut-o mulți dintre noi, cărora le plac compilatoarele. Cred că răspunsul scurt este că, dacă ai putea face acest lucru și îl vei face ușor de utilizat, oamenii l-ar folosi . Singura problemă este că ‘ este mare ” dacă „.
- Ați analizat Lisp ? ” [Este ‘ s] nu atât că Lisp are o sintaxă ciudată, cât Lisp nu are sintaxă. Scrieți programe în arborele de analiză care sunt generate în cadrul compilatorului atunci când sunt analizate alte limbi. Dar acești copaci analizați sunt pe deplin accesibile programelor dvs. Puteți scrie programe care să le manipuleze. ”
Răspuns
Multe dintre aceste instrumente funcționează funcționează direct cu arborele abstract de sintaxă (sau mai bine zis, un direct către -o vizualizare a acestuia). Aceasta include Blockly, pe care l-ați „văzut”, precum și celelalte limbi și editori bazate pe blocuri ( Scratch , Cod creion / Droplet , Snap! , GP , Tiled Grace și așa mai departe).
Aceste sisteme nu au prezintă o reprezentare tradițională a graficului de vârf și margine, din motive explicate în altă parte (spațiu și, de asemenea, dificultăți de interacțiune), dar reprezintă direct un copac. Un nod sau bloc este un copil al altuia dacă este direct, fizic în interiorul părintelui.
Am construit unul dintre aceste sisteme ( Tiled Grace , hârtie , hârtie ). Vă pot asigura, funcționează foarte mult cu AST direct: ceea ce vedeți pe ecran este o reprezentare exactă a arborelui de sintaxă, ca elemente DOM imbricate (deci, un copac!).
Acesta este AST al unui cod. Rădăcina este un nod de apel de metodă „pentru … face”. Acest nod are câțiva copii, începând cu „_ .. _”, care are în sine doi copii, un nod „1” și un nod „10”. Ceea ce apare pe ecran este exact ceea ce scuipă backend-ul compilatorului în mijlocul procesului – așa funcționează în mod fundamental sistemul.
Dacă doriți, vă puteți gândi la acesta ca la un aspect standard al arborelui cu marginile îndreptate spre ecran spre dvs. (și ocluse de blocul din fața lor), dar cuibărirea este un mod la fel de valid de a arăta un copac ca o diagramă de vârf.
De asemenea, va „face călătoria dus-întors de la sursă la nod-grafic și apoi înapoi din nou la sursă atunci când este necesar „. De fapt, puteți vedea acest lucru când faceți clic pe” Vizualizare cod „în partea de jos. Dacă modificați textul, acesta va fi re- analizat și arborele rezultat redat pentru a fi editat din nou și, dacă modificați blocurile, același lucru se întâmplă cu sursa.
Codul creionului face în esență același lucru cu, în acest moment, o interfață mai bună . Blocurile pe care le folosește sunt o vedere grafică a CoffeeScript AST.La fel și celelalte sisteme bazate pe blocuri sau țigle, în mare, deși unele dintre ele nu fac ca aspectul de cuibărire să fie la fel de clar în reprezentarea vizuală, iar multe nu au un limbaj textual în spate, astfel încât arborele de sintaxă „poate fi un pic iluziv, dar principiul este acolo.
Ceea ce îți lipsește, atunci este că aceste sisteme chiar funcționează direct cu arborele de sintaxă abstract. Ceea ce vedeți și manipulați este o redare eficientă din punct de vedere spațial a unui copac, în multe cazuri, literalmente, AST produce un compilator sau un analizor.
Răspuns
Cel puțin două motive:
-
Deoarece codul sursă este o reprezentare mult mai concisă. Așezarea unui AST ca grafic ar ocupa mult mai multe bunuri imobiliare vizuale.
Premiul programatorilor având un context cât mai mare posibil – adică, având un număr cât mai mare de coduri prezente simultan pe ecran în același timp. Contextul îi ajută să gestioneze mai bine complexitate. (Acesta este un motiv pentru care mulți progr Amers utilizează aceste fonturi mici nebunești și ecrane enorme de 30 „.)
Dacă am încerca să afișăm AST ca grafic sau arborescență, atunci cantitatea de cod pe care ați putea să o încadrați pe un singur ecran ar fi mult mai mică decât atunci când este reprezentat ca cod sursă. Aceasta reprezintă o pierdere uriașă pentru productivitatea dezvoltatorilor.
-
AST sunt destinate programării compilatorului, nu pentru înțelegerea ușoară de către programatori. Dacă ați lua o reprezentare AST existentă și ați afișa-o vizual, probabil că ar fi mai greu de înțeles de dezvoltatori, deoarece AST-urile nu au fost concepute pentru a fi ușor de învățat pentru dezvoltatori.
În schimb, codul sursă de obicei este conceput pentru a putea fi citit / ușor de înțeles de către dezvoltatori; acesta este în mod normal un criteriu critic de proiectare pentru codul sursă, dar nu și pentru AST. AST-urile trebuie înțelese numai de către compușii de compilare, nu de către dezvoltatorii obișnuiți.
Și, în orice caz, limba AST ar fi o a doua limbă pe care dezvoltatorii trebuie să o învețe, pe lângă limba sursă. Nu este un câștig.
Consultați și https://softwareengineering.stackexchange.com/q/119463/34181 pentru câteva motive potențiale suplimentare.
Comentarii
- ” În schimb, codul sursă este conceput pentru a putea fi citit / ușor de înțeles de către dezvoltatori ” – contraexemplu: majoritatea esolangurilor, Perl, Lisp
- ” Becaus Codul sursă este o reprezentare mult mai concisă. ” ” limba AST ar fi o a doua limbă pe care dezvoltatorii trebuie să o învețe, pe lângă limba sursă ” – acestea sunt argumente împotriva toate PL-urile vizuale, dar nu ajută la explicarea distincției de care este preocupat OP.
- ” (Acel ‘ este unul dintre motivele pentru care mulți programatori folosesc aceste fonturi mici și nebunești și enorme 30 ” ecrane.) ” – dacă aveți nevoie de un ecran mare pentru a vizualiza suficient context, poate că ‘ sunteți cod de spaghete? 😉
- @Raphael Poate, dar este ‘ mai puțin efort să arunci bani decât refactoring!
- @JanDvorak, .. .LISP este un contraexemplu deoarece AST este limbajul – ceea ce îi conferă puterea sa expresivă; scrierea codului LISP care recompilează celălalt cod LISP este la fel de ușor ca scrierea codului care modifică structurile de date standard LISP … care sunt exact ceea ce este scris codul LISP . ‘ este motivul pentru care ‘ a durat peste jumătate de secol – familia ‘ Proiectarea este neobișnuit de expresivă. Go a trebuit să aibă extensiile sale asincronizate adânc în limbă și timp de rulare; pentru Clojure, ‘ este doar o bibliotecă. A se vedea, de asemenea: Baterea mediilor .
Răspuns
AST tipic pentru compilatori este destul de complex și detaliat. Reprezentarea grafică direcționată ar deveni rapid destul de greu de urmărit. Dar există două zone mari ale CS în care sunt utilizate AST-urile.
- Limbile Lisp sunt de fapt scrise ca AST. Codul sursă al programului este scris ca liste și este utilizat direct de compilator și / sau interpret (în funcție de varianta utilizată).
- Limbaje de modelare, de ex. UML și multe limbaje specifice domeniului vizual utilizează notații grafice care sunt grafice de sintaxă abstractă eficiente (ASG) la un nivel de abstractizare mai ridicat decât limbajul tipic de uz general AST.