Jeg har funnet flere visuelle programmeringsverktøy med åpen kildekode som Blockly og venner, og andre prosjekter som vert hos Github, men kunne ikke finne noen som fungerer direkte med det abstrakte syntaksetreet.
Hvorfor er det?
I «m når jeg oppdaget at hver kompilator der ute har en fase i kompileringsprosessen der den analyserer kildekoden til en AST, var det åpenbart for meg at noen visuelle programmeringsverktøy kunne dra nytte av dette for å gi programmereren måter å redigere AST direkte på en visuell måte, og også å gjøre tur-retur fra kilde til node-graf og deretter tilbake igjen til kilde når det er nødvendig.
For eksempel kan man tro at fra JavaScript AST Visualizer til et faktisk JavaSript visuelt programmeringsverktøy er det ikke for stor forskjell.
, hva mangler jeg?
Kommentarer
- AST-er er veldig omfattende og ikke veldig praktiske for programmering. De var designet for kompilatorer, ikke programmerere.
- no.wikipedia.org/wiki/Structure_editor
- Hva gjør du mener med » arbeide direkte med det abstrakte syntakstreet «? Uten tvil redigerer alle blokkbaserte verktøy som Blockly AST: de representerer kanter ved å hekke (eller stable, hvis du foretrekker å se det på den måten), og brukeren kan redigere treet ved å si og si. / li>
- Det ‘ er et flott spørsmål mange av oss som liker kompilatorer har hatt. Jeg tror det korte svaret er at hvis du kunne gjøre dette og gjøre det brukervennlig, ville folk bruke det. Det eneste problemet er at ‘ er stor » hvis «.
- Har du sett på Lisp ? » [Det ‘ s] ikke så mye at Lisp har en merkelig syntaks som at Lisp ikke har noen syntaks. Du skriver programmer i parse-trærne som blir generert i kompilatoren når andre språk blir analysert. Men disse parse-trærne er fullt tilgjengelige for programmene dine. Du kan skrive programmer som manipulerer dem. »
Svar
Mange av disse verktøyene gjør fungerer direkte med det abstrakte syntaksetreet (eller rettere sagt en direkte en-til -en visualisering av det). Dette inkluderer Blockly, som du har sett, og de andre blokkbaserte språkene og redaktørene liker det ( Scratch , Blyantkode / Droplet , Snap! , GP , Tiled Grace , og så videre).
Disse systemene trenger ikke viser en tradisjonell vertex-og-kant-grafrepresentasjon, av årsaker som er forklart andre steder (mellomrom og også samhandlingsproblemer), men de representerer direkte et tre. En node, eller blokk, er et barns barn hvis det er direkte, fysisk inne i foreldrene.
Jeg bygde ett av disse systemene ( Tiled Grace , paper , paper ). Jeg kan forsikre deg om at det er veldig mye å jobbe med AST direkte: det du ser på skjermen er en nøyaktig representasjon av syntaks-treet, som nestede DOM-elementer (altså et tre!).
Dette er AST for en eller annen kode. Roten er en metodeanropskode «for … gjør». Den noden har noen barn, og begynner med «_ .. _», som i seg selv har to barn, en «1» -node og en «10» -node. Det som kommer opp på skjermen er nøyaktig hva kompilatorbackend spytter ut midt i prosessen – det er grunnleggende hvordan systemet fungerer.
Hvis du vil, kan du tenke på det som et standard treoppsett. med kantene som peker ut av skjermen mot deg (og okkludert av blokken foran dem), men hekking er like gyldig en måte å vise et tre på som et toppunktdiagram.
Det vil også «gjøre tur-retur fra kilde til nodegraf og deretter tilbake igjen til kilde når det er behov «. Faktisk kan du se at det skjer når du klikker» Kodevisning «nederst. Hvis du endrer teksten, vil den være analysert og det resulterende treet blir gjengitt slik at du kan redigere dem igjen, og hvis du endrer blokkene, skjer det samme med kilden.
Blyantkode gjør egentlig det samme med, på dette punktet, et bedre grensesnitt . Blokkene den bruker er en grafisk oversikt over CoffeeScript AST.Det samme gjør de andre blokk- eller flisebaserte systemene, stort sett, selv om noen av dem ikke gjør hekkingsaspektet ganske så tydelig i den visuelle representasjonen, og mange har ikke et faktisk tekstspråk bak seg, så » syntaks-treet «kan være litt illusivt, men prinsippet er der.
Det du da mangler, er at disse systemene virkelig fungerer direkte med abstrakt syntaks-tre. Det du ser og manipulerer er en plasseffektiv gjengivelse av et tre, i mange tilfeller bokstavelig talt AST-en som en kompilator eller parser produserer.
Svar
Minst to grunner:
-
Fordi kildekoden er en mye mer kortfattet fremstilling. Legge ut en AST som en graf ville ta opp mye mer visuell eiendom.
Programmørprisen har så mye kontekst som mulig – dvs. å ha så mye kode til stede samtidig på skjermen. Kontekst hjelper dem med å bedre administrere kompleksitet. (Det er en grunn til at mange progr ammers bruker disse sprø små skriftene og enorme 30 «skjermbilder.)
Hvis vi prøvde å vise AST som et diagram eller tre, ville mengden kode du kunne passe på en enkelt skjerm være mye mindre. enn når den er representert som kildekode. Det er et stort tap for utviklerens produktivitet.
-
AST er ment for programmering av kompilatorer, ikke for enkel forståelse av programmerere. Hvis du tok en eksisterende AST-representasjon og viste den visuelt, ville det sannsynligvis være vanskeligere for utviklere å forstå, fordi AST-er ikke var designet for å være enkle for utviklere å lære.
I motsetning til dette er kildekoden vanligvis er designet for å være leselig / forståelig av utviklere; det er normalt et kritisk designkriterium for kildekoden, men ikke for AST-er. AST-er trenger bare å forstås av kompilatorforfatterne, ikke av hverdagsutviklere.
Og uansett ville AST-språket være et andrespråk som utviklere må lære, i tillegg til kildespråket. Ikke en gevinst.
Se også https://softwareengineering.stackexchange.com/q/119463/34181 av noen ekstra potensielle årsaker.
Kommentarer
- » I motsetning er kildekoden designet for å være lesbar / forståelig av utviklere » – moteksempel: de fleste esolangs, Perl, Lisp
- » Becaus kildekoden er en mye mer kortfattet fremstilling. «; » AST-språket ville være et andrespråk som utviklere må lære, i tillegg til kildespråket » – dette er argumenter mot alle visuelle PL-er, men hjelper ikke til å forklare skillet OP er bekymret for.
- » (At ‘ er en grunn til at mange programmerere bruker disse sprø små skriftene og enorme 30 » skjermer.) » – hvis du trenger en storskjerm for å se nok kontekst, kanskje du ‘ er spaghetti-koding? 😉
- @Raphael Kanskje, men det ‘ er mindre innsats for å kaste penger på det enn refactoring!
- @JanDvorak, .. .LISP er et moteksempel fordi AST er språket – og det er det som gir det sin uttrykkende kraft; å skrive LISP-kode som kompilerer den andre LISP-koden din, er like enkelt som å skrive kode som endrer standard LISP-datastrukturer … hvilke er nøyaktig hva LISP-koden er skrevet i . Der ‘ en grunn til at det ‘ s varte i over et halvt århundre – familien ‘ s design er uvanlig uttrykksfull. Go måtte ha asynk-utvidelsene dypt inn i språket og kjøretiden; for Clojure er det ‘ bare et bibliotek. Se også: Slå gjennomsnittene .
Svar
Den typiske AST fra kompilatorer er ganske komplisert og ordentlig. Den dirigerte grafrepresentasjonen vil raskt bli ganske vanskelig å følge. Men det er to store områder av CS der AST brukes.
- Lisp-språk skrives faktisk som AST. Programkildekoden skrives som lister og brukes direkte av kompilatoren og / eller tolk (avhengig av hvilken variant som brukes).
- Modelleringsspråk, f.eks. UML og mange visuelle domenespesifikke språk bruker grafiske notasjoner som er effektive abstrakte syntaksgrafer (ASG) på et høyere abstraksjonsnivå enn det typiske generelle språket AST.