Ik “heb verschillende open source visuele programmeertools gevonden, zoals Blockly en vrienden, en andere projecten die worden gehost op Github, maar ik kon er geen vinden die direct werken met de abstracte syntaxisboom.
Waarom is dat?
Ik “m te vragen, want toen ik eenmaal ontdekte dat elke compiler die er is een fase in het compilatieproces heeft waarin het de broncode parseert naar een AST, was het voor mij duidelijk dat sommige visuele programmeertools hiervan zouden kunnen profiteren om de programmeur manieren te geven om de AST direct op een visuele manier, en ook om de heen-en-terugreis te doen van bron naar node-graph en dan weer terug naar bron wanneer dat nodig is.
Men zou bijvoorbeeld kunnen denken dat uit de JavaScript AST Visualizer naar een echte JavaSript visuele programmeertool is er niet al te veel verschil.
Dus , wat mis ik?
Reacties
- ASTs zijn erg uitgebreid en niet erg handig om te programmeren. Ze zijn ontworpen voor compilers, niet voor programmeurs.
- en.wikipedia.org/wiki/Structure_editor
- Wat doen je bedoelt met ” rechtstreeks werken met de abstracte syntaxisboom “? Ongetwijfeld bewerken alle blokgebaseerde tools zoals Blockly de AST: ze vertegenwoordigen randen door te nesten (of te stapelen, als je het liever zo ziet), en de gebruiker kan de boom bewerken door (bijvoorbeeld) slepen en neerzetten. / li>
- Het ‘ is een geweldige vraag die velen van ons die graag compilers hebben gehad. Ik denk dat het korte antwoord is dat als je dit zou kunnen doen en het gebruiksvriendelijk zou kunnen maken, mensen het zouden gebruiken. Het enige probleem is dat ‘ een grote ” is als “.
- Heb je Lisp bekeken? ” [Het ‘ s] niet zozeer dat Lisp een vreemde syntaxis heeft, maar dat Lisp geen syntaxis heeft. U schrijft programmas in de ontleedstructuren die binnen de compiler worden gegenereerd wanneer andere talen worden ontleed. Maar deze ontleedbomen zijn volledig toegankelijk voor uw programmas. Je kunt programmas schrijven die ze manipuleren. ”
Answer
Veel van deze tools werken rechtstreeks met de abstracte syntaxisboom (of liever, een directe -een visualisatie ervan). Dat omvat Blockly, dat je “hebt gezien, en de andere op blokken gebaseerde talen en editors die het leuk vinden ( Scratch , Potloodcode / Druppel , Snap! , GP , Tiled Grace , enzovoort).
Die systemen tonen een traditionele weergave van vertex-en-randgrafieken, om redenen die elders worden uitgelegd (ruimte, en ook moeilijkheidsgraad van interactie), maar ze vertegenwoordigen rechtstreeks een boom. Het ene knooppunt, of blok, is een kind van een ander als het zich direct, fysiek binnen de ouder bevindt.
Ik heb een van deze systemen gebouwd ( Tiled Grace , paper , paper ). Ik kan je verzekeren dat het heel erg is om rechtstreeks met de AST te werken: wat je op het scherm ziet, is een exacte weergave van de syntaxisboom, als geneste DOM-elementen (dus een boom!).
Dit is de AST van een bepaalde code. De root is een methodeaanroepknooppunt “for … do”. Dat knooppunt heeft enkele kinderen, beginnend met “_ .. _”, die zelf twee kinderen heeft, een knooppunt “1” en een knooppunt “10”. Wat op het scherm verschijnt, is precies wat de compiler-backend uitspuugt in het midden van het proces – dat is fundamenteel hoe het systeem werkt.
Als je wilt, kun je het zien als een standaard boomstructuur. met de randen naar u toe gericht (en afgesloten door het blok ervoor), maar nesten is een even geldige manier om een boom te tonen als een hoekpuntdiagram.
Het zal ook “doen de heen- en terugreis van bron naar knooppuntgrafiek en dan weer terug naar de bron wanneer dat nodig is “. In feite kun je zien dat dit gebeurt als je onderaan op” Codeweergave “klikt. Als je de tekst wijzigt, wordt het opnieuw geparseerd en de resulterende boom gerenderd zodat u deze opnieuw kunt bewerken, en als u de blokken wijzigt, gebeurt hetzelfde met de broncode.
Pencil Code doet in wezen hetzelfde met, op dit punt, een betere interface . De blokken die het gebruikt, zijn een grafische weergave van de CoffeeScript AST.Dat geldt over het algemeen ook voor de andere op blokken of tegels gebaseerde systemen, hoewel sommige ervan het nestaspect niet zo duidelijk maken in de visuele weergave, en veel geen echte tekstuele taal achter zich hebben, dus de syntax tree “kan een beetje illusoir zijn, maar het principe is aanwezig.
Wat je dus mist, is dat deze systemen echt werken met de abstracte syntaxisboom. Wat je ziet en manipuleert, is een ruimtebesparende weergave van een boom, in veel gevallen letterlijk de AST die een compiler of parser produceert.
Antwoord
Ten minste twee redenen:
-
Omdat broncode een veel beknoptere weergave is. Een AST opmaken als een grafiek zou veel meer visueel onroerend goed in beslag nemen.
Programmeurs prijzen het als ze zoveel mogelijk context hebben – dat wil zeggen, zoveel mogelijk code tegelijk op het scherm hebben. Context helpt hen om beter te beheren complexiteit. (dat is een reden waarom veel progr ammers gebruiken deze gekke kleine lettertypen en enorme 30-inch schermen.)
Als we zouden proberen de AST weer te geven als een grafiek of boom, dan zou de hoeveelheid code die je op een enkel scherm zou kunnen passen veel minder zijn dan wanneer het wordt weergegeven als broncode. Dat is een enorm verlies voor de productiviteit van ontwikkelaars.
-
ASTs zijn bedoeld voor het programmeren van compilers, niet om ze gemakkelijk te begrijpen voor programmeurs. Als je een bestaande AST-representatie zou nemen en deze visueel zou weergeven, zou het waarschijnlijk moeilijker zijn voor ontwikkelaars om te begrijpen, omdat ASTs “niet zo ontworpen zijn dat ze gemakkelijk te leren zijn voor ontwikkelaars.
In tegenstelling daarmee is de broncode meestal is ontworpen om leesbaar / begrijpelijk te zijn voor ontwikkelaars; dat is normaal gesproken een kritisch ontwerpcriterium voor de broncode, maar niet voor ASTs. ASTs hoeven alleen te worden begrepen door de compilerschrijvers, niet door alledaagse ontwikkelaars.
En in ieder geval zou de AST-taal een tweede taal zijn die ontwikkelaars moeten leren, naast de brontaal. Geen overwinning.
Zie ook https://softwareengineering.stackexchange.com/q/119463/34181 voor enkele aanvullende mogelijke redenen.
Opmerkingen
- ” Broncode daarentegen is ontworpen om leesbaar / begrijpelijk te zijn door ontwikkelaars ” – tegenvoorbeeld: meeste esolangs, Perl, Lisp
- ” Becaus De broncode is een veel beknoptere weergave. “; ” de AST-taal zou een tweede taal zijn die ontwikkelaars moeten leren, naast de brontaal ” – dit zijn argumenten tegen alle visuele PLs, maar helpt niet om het onderscheid uit te leggen waar het OP zich zorgen over maakt.
- ” (Dat ‘ is een reden waarom veel programmeurs deze gekke kleine lettertypen en enorme 30 ” schermen gebruiken.) ” – if je hebt een groot scherm nodig om voldoende context te zien, misschien ‘ spaghetti-codering? 😉
- @Raphael Misschien, maar het ‘ kost minder moeite om er geld in te gooien dan refactoring!
- @JanDvorak, .. .LISP is een tegenvoorbeeld omdat de AST de taal is – en dat is wat haar zijn expressieve kracht geeft; het schrijven van LISP-code die uw andere LISP-code opnieuw compileert, is net zo eenvoudig als het schrijven van code die de standaard LISP-datastructuren wijzigt … waarin precies is waarin LISP-code is geschreven . Er ‘ is een reden waarom het ‘ s meer dan een halve eeuw heeft geduurd – de familie ‘ s ontwerp is ongebruikelijk expressief. Go moest zijn asynchrone extensies diep in de taal en runtime laten peilen; voor Clojure is het ‘ slechts een bibliotheek. Zie ook: Beating the averages .
Answer
De typische AST door compilers is nogal complex en uitgebreid. De gerichte grafische weergave zou al snel vrij moeilijk te volgen worden. Maar er zijn twee grote gebieden van CS waar ASTs worden gebruikt.
- Lisp-talen worden feitelijk als AST geschreven. De broncode van het programma is geschreven als lijsten en direct gebruikt door de compiler en / of tolk (afhankelijk van welke variant wordt gebruikt).
- Modelleringstalen, bijv. UML en veel visuele domeinspecifieke talen gebruiken grafische notaties die effectieve abstracte syntaxisgrafieken (ASG) zijn op een hoger abstractieniveau dan de typische algemene taal AST.