Jag har hittat flera visuella programmeringsverktyg med öppen källkod som Blockly och vänner och andra projekt som värd på Github, men kunde inte hitta någon som fungerar direkt med det abstrakta syntaxträdet.
Varför är det?
I ”m frågar för att när jag upptäckte att varje kompilator där ute har en fas i kompileringsprocessen där den analyserar källkoden till en AST, var det uppenbart för mig att vissa visuella programmeringsverktyg kunde dra nytta av detta för att ge programmeraren sätt att redigera AST direkt på ett visuellt sätt, och även att göra tur och retur från källa till nodgraf och sedan tillbaka igen till källa när det behövs.
Till exempel kan man tro att från JavaScript AST Visualizer till ett verkligt JavaSript-visuellt programmeringsverktyg finns det inte för stor skillnad.
, vad saknar jag?
Kommentarer
- AST: er är mycket detaljerade och inte särskilt praktiska för programmering. De var utformade för kompilatorer, inte för programmerare.
- sv.wikipedia.org/wiki/Structure_editor
- Vad gör menar du med ” arbeta direkt med det abstrakta syntaxträdet ”? Förmodligen redigerar alla blockbaserade verktyg som Blockly AST: de representerar kanter genom att häcka (eller stapla, om du föredrar att se det på det sättet), och användaren kan redigera trädet genom att (säga) dra och släppa. / li>
- Det ’ är en stor fråga som många av oss som gillar kompilatorer har haft. Jag tror att det korta svaret är att om du skulle kunna göra detta och göra det användarvänligt skulle människor använda det. Det enda problemet är att ’ är en stor ” om ”.
- Har du tittat på Lisp ? ” [Det ’ s] inte så mycket att Lisp har en konstig syntax som att Lisp inte har någon syntax. Du skriver program i parse-träd som genereras i kompilatorn när andra språk analyseras. Men dessa parse träd är fullt tillgängliga för dina program. Du kan skriva program som manipulerar dem. ”
Svar
Många av dessa verktyg gör arbetar direkt med det abstrakta syntaxträdet (eller snarare en direkt en-till -en visualisering av det). Det inkluderar Blockly, som du har sett, och andra blockbaserade språk och redaktörer gillar det ( Scratch , Pencil Code / Droplet , Snap! , GP , Tiled Grace , och så vidare).
Dessa system har inte visa en traditionell vertex-och-kant-grafrepresentation, av skäl som förklaras någon annanstans (utrymme och även interaktionsproblem), men de representerar direkt ett träd. En nod eller block är ett barns barn om det är direkt, fysiskt inuti föräldern.
Jag byggde ett av dessa system ( Tiled Grace , papper , papper ). Jag kan försäkra dig om att det fungerar väldigt mycket med AST direkt: vad du ser på skärmen är en exakt representation av syntaxträdet, som kapslade DOM-element (så, ett träd!).
Detta är AST för någon kod. Roten är en metodanropsnod ”för … gör”. Den noden har några barn, som börjar med ”_ .. _”, som i sig har två barn, en ”1” -nod och en ”10” -nod. Vad som kommer upp på skärmen är exakt vad kompilatorns backend spottar ut mitt i processen – det är i grunden hur systemet fungerar.
Om du vill kan du tänka på det som en standard trädlayout med kanterna som pekar ut från skärmen mot dig (och tilltäppt av blocket framför dem), men häckning är lika giltigt som ett sätt att visa ett träd som ett toppdiagram.
Det kommer också att ”göra tur och retur från källa till noddiagram och sedan tillbaka igen till källa när det behövs ”. Du kan faktiskt se att det händer när du klickar på” Kodvy ”längst ner. Om du ändrar texten kommer den att vara analyseras och det resulterande trädet återges för att du ska kunna redigera igen, och om du ändrar blocken händer samma sak med källan.
Pencil Code gör i princip samma sak med, vid denna punkt, ett bättre gränssnitt . Blocken som används är en grafisk vy av CoffeeScript AST.Så gör de andra block- eller kakelbaserade systemen i stort sett, även om vissa av dem inte gör häckningsaspekten lika tydlig i den visuella representationen, och många har inte ett verkligt textspråk bakom sig så ” syntaxträd ”kan vara lite illusivt, men principen är där.
Vad du saknar är att dessa system verkligen arbetar direkt med abstrakt syntaxträd. Det du ser och manipulerar är en rymdeffektiv återgivning av ett träd, i många fall bokstavligen den AST som en kompilator eller parser producerar.
Svar
Minst två skäl:
-
Eftersom källkoden är en mycket mer kortfattad representation. Att lägga ut en AST som ett diagram skulle ta upp mycket mer visuell fastighet.
Programmerare prissätter att ha så mycket sammanhang som möjligt – dvs att ha så mycket kod närvarande samtidigt på skärmen samtidigt. Kontext hjälper dem att hantera bättre komplexitet. (Det är en anledning till att många progr ammers använder dessa galna små teckensnitt och enorma 30 ”skärmar.)
Om vi försökte visa AST som ett diagram eller träd, skulle mängden kod som du kunde passa på en enda skärm vara mycket mindre än när den representeras som källkod. Det är en enorm förlust för utvecklarens produktivitet.
-
AST ”är avsedda för kompileringsprogrammering, inte för enkel förståelse för programmerare. Om du tog en befintlig AST-representation och visade den visuellt skulle det förmodligen vara svårare för utvecklare att förstå, eftersom AST inte var utformade för att vara lätta för utvecklare att lära sig.
Däremot brukar källkoden är utformad för att vara läsbar / förståelig för utvecklare; det är normalt ett kritiskt designkriterium för källkod, men inte för AST. AST behöver bara förstås av kompilatörförfattarna, inte av vardagliga utvecklare.
Och i vilket fall som helst skulle AST-språket vara ett andra språk som utvecklare måste lära sig, förutom källspråket. Inte en vinst.
Se även https://softwareengineering.stackexchange.com/q/119463/34181 av ytterligare potentiella skäl.
Kommentarer
- ” Däremot är källkoden utformad för att vara läsbar / förståelig för utvecklare ” – motexempel: de flesta esolangs, Perl, Lisp
- ” Becaus källkoden är en mycket mer kortfattad representation. ”; ” AST-språket skulle vara ett andra språk som utvecklare måste lära sig, förutom källspråket ” – detta är argument mot alla visuella PL-filer men hjälper inte till att förklara skillnaden som OP är bekymrad över.
- ” (That ’ är en anledning till att många programmerare använder dessa galna små teckensnitt och enorma 30 ” skärmar.) ” – om du behöver en storbildsskärm för att se tillräckligt med sammanhang, kanske ’ är spagetti-kodande? 😉
- @Raphael Kanske, men det ’ är mindre ansträngning för att kasta pengar på det än att refactoring!
- @JanDvorak, .. .LISP är ett motexempel eftersom AST är språket – vilket är det som ger det sin uttrycksfulla kraft; att skriva LISP-kod som kompilerar din andra LISP-kod är lika enkelt som att skriva kod som ändrar standard LISP-datastrukturer … vilka är exakt vad LISP-koden skrivs i . Där ’ är anledningen till att det ’ s varade i över ett halvt sekel – familjen ’ s design är ovanligt uttrycksfull. Go var tvungen att få sina async-tillägg djupt in i språket och körtiden; för Clojure är det ’ bara ett bibliotek. Se även: Slå medeltalen .
Svar
Den typiska AST av kompilatorer är ganska komplex och omfattande. Den riktade grafrepresentationen skulle snabbt bli ganska svår att följa. Men det finns två stora områden av CS där AST används.
- Lisp-språk skrivs faktiskt som AST. Programkällkoden skrivs som listor och används direkt av kompilatorn och / eller tolk (beroende på vilken variant som används).
- Modelleringsspråk, t.ex. UML och många visuella domänspecifika språk använder grafiska notationer som är effektiva abstrakta syntaxdiagram (ASG) vid en högre abstraktionsnivå än det typiska allmänna språket AST.