Jeg har fundet flere open source visuelle programmeringsværktøjer som Blockly og venner og andre projekter hostet hos Github, men kunne ikke finde nogen, der fungerer direkte med det abstrakte syntaks træ.
Hvorfor er det?
I “m spørger, for når jeg først opdagede, at hver kompilator derude har en fase i kompileringsprocessen, hvor den analyserer kildekoden til en AST, var det indlysende for mig, at nogle visuelle programmeringsværktøjer kunne drage fordel af dette for at give programmøren måder at redigere AST direkte på en visuel måde, og også at gøre rundtur fra kilde til knudegraf og derefter tilbage igen til kilde, når det er nødvendigt.
For eksempel kunne man tro, at fra JavaScript AST Visualizer til et faktisk visuelt JavaSript-programmeringsværktøj er der ikke for stor forskel.
, hvad mangler jeg?
Kommentarer
- ASTer er meget detaljerede og ikke særlig praktiske til programmering. De var designet til kompilatorer, ikke programmører.
- da.wikipedia.org/wiki/Structure_editor
- Hvad gør mener du med ” arbejde direkte med det abstrakte syntaks træ “? Formentlig redigerer alle de blokbaserede værktøjer som Blockly AST: de repræsenterer kanter ved at indlejre (eller stable, hvis du foretrækker at se det på den måde), og brugeren kan redigere træet ved (sige) træk og slip.
- Det ‘ er et stort spørgsmål, som mange af os, der kan lide kompilatorer, har haft. Jeg tror, det korte svar er, at hvis du kunne gøre dette og gøre det brugervenligt, ville folk bruge det. Det eneste problem er, at ‘ er en stor ” hvis “.
- Har du undersøgt Lisp ? ” [Det ‘ s] ikke så meget, at Lisp har en underlig syntaks, da Lisp ikke har nogen syntaks. Du skriver programmer i parse-træerne, der genereres i compileren, når andre sprog parses. Men disse parse træer er fuldt tilgængelige for dine programmer. Du kan skrive programmer, der manipulerer dem. ”
Svar
Mange af disse værktøjer gør arbejder direkte med det abstrakte syntaks træ (eller rettere en direkte en-til -en visualisering af det). Det inkluderer Blockly, som du har set, og de andre blokbaserede sprog og redaktører kan lide det ( Scratch , Blyantkode / Dråbe , Snap! , GP , Tiled Grace og så videre).
Disse systemer don t viser en traditionel vertex-and-edge-grafrepræsentation af grunde, der er forklaret andetsteds (rum og også interaktionsvanskeligheder), men de repræsenterer direkte et træ. Én node eller blok er et barns barn, hvis det er direkte, fysisk inde i forældrene.
Jeg byggede et af disse systemer ( Tiled Grace , papir , papir ). Jeg kan forsikre dig om, at det er meget at arbejde med AST direkte: hvad du ser på skærmen er en nøjagtig gengivelse af syntaksetræet som indlejrede DOM-elementer (altså et træ!).
Dette er AST for en eller anden kode. Roden er en metodeopkaldsknude “til … gør”. Den node har nogle børn, der starter med “_ .. _”, som i sig selv har to børn, en “1” node og en “10” node. Hvad der kommer op på skærmen er præcis, hvad kompilatorens backend spytter ud midt i processen – det er grundlæggende, hvordan systemet fungerer.
Hvis du vil, kan du tænke på det som et standard trælayout. med kanterne pegende ud af skærmen mod dig (og tilstoppet af blokken foran dem), men indlejring er lige så gyldig som en måde at vise et træ på som et toppunktdiagram.
Det vil også “gøre tur-retur fra kilde til node-graf og derefter tilbage igen til kilde, når det er nødvendigt “. Faktisk kan du se, at det sker, når du klikker på” Kodevisning “i bunden. Hvis du ændrer teksten, vil den være parset og det resulterende træ gengivet for dig at redigere igen, og hvis du ændrer blokke, sker det samme med kilden.
Blyantkode gør stort set det samme med, på dette tidspunkt, en bedre grænseflade . De blokke, den bruger, er en grafisk visning af CoffeeScript AST.Så gør de andre blok- eller flise-baserede systemer stort set, selvom nogle af dem ikke gør indlejringsaspektet lige så klart i den visuelle repræsentation, og mange har ikke et faktisk tekstsprog bag sig, så ” syntaks træ “kan være en smule illusivt, men princippet er der.
Hvad du mangler, er, at disse systemer virkelig arbejder direkte med abstrakt syntaks træ. Hvad du ser og manipulerer er en pladseffektiv gengivelse af et træ, i mange tilfælde bogstaveligt den AST, som en kompilator eller parser producerer.
Svar
Mindst to grunde:
-
Fordi kildekoden er en meget mere kortfattet repræsentation. Udformning af en AST som en graf ville tage meget mere visuel ejendom.
Programmørpræmien har så meget kontekst som muligt – dvs. at have så meget kode til stede på én gang på skærmen på samme tid. Kontekst hjælper dem med bedre at styre kompleksitet. (Det er en af grundene til, at mange progr ammers bruger disse vanvittige små skrifttyper og enorme 30 “-skærme.)
Hvis vi forsøgte at vise AST som en graf eller et træ, ville den mængde kode, som du kunne passe på en enkelt skærm, være meget mindre end når det er repræsenteret som kildekode. Det er et stort tab for udviklerens produktivitet.
-
ASTer er beregnet til programmering af compiler og ikke til let forståelse af programmører. Hvis du tog en eksisterende AST-repræsentation og viste den visuelt, ville det sandsynligvis være sværere for udviklere at forstå, fordi ASTer ikke var designet til at være lette for udviklere at lære.
I modsætning hertil er kildekoden normalt er designet til at være læseligt / forståeligt af udviklere; det er normalt et kritisk designkriterium for kildekode, men ikke for ASTer. ASTer skal kun forstås af kompilatorforfatterne, ikke af daglige udviklere.
Og under alle omstændigheder ville AST-sproget være et andet sprog, som udviklere skal lære ud over kildesproget. Ikke en gevinst.
Se også https://softwareengineering.stackexchange.com/q/119463/34181 af nogle yderligere potentielle årsager.
Kommentarer
- ” I modsætning hertil er kildekoden designet til at være læselig / forståelig af udviklere ” – modeksempel: de fleste esolangs, Perl, Lisp
- ” Becaus kildekoden er en meget mere kortfattet repræsentation. “; ” AST-sproget ville være et andet sprog, som udviklere skal lære, ud over kildesproget ” – dette er argumenter mod alle visuelle PLer, men hjælper ikke med at forklare den sondring, OP er bekymret for.
- ” (At ‘ er en af grundene til, at mange programmører bruger disse skøre små skrifttyper og enorme 30 ” skærme.) ” – hvis du har brug for en stor røvskærm for at se nok kontekst, måske ‘ er spaghetti-kodning? 😉
- @Raphael Måske, men det ‘ s mindre indsats for at kaste penge på det end refactoring!
- @JanDvorak, .. .LISP er et modeksempel, fordi AST er sproget – hvilket er det, der giver det sin udtryksfulde kraft; at skrive LISP-kode, der kompilerer din anden LISP-kode, er lige så let som at skrive kode, der ændrer standard LISP-datastrukturer … hvilke er præcis, hvad LISP-kode er skrevet i . Der ‘ en grund til, at det ‘ s varede i over et halvt århundrede – familien ‘ s design er usædvanligt udtryksfuldt. Go måtte have sine asynk-udvidelser lodret dybt ind i sproget og runtime; til Clojure er det ‘ bare et bibliotek. Se også: At slå gennemsnittet .
Svar
Den typiske AST fra kompilatorer er ret kompleks og detaljeret. Den dirigerede grafrepræsentation ville hurtigt blive ret svær at følge. Men der er to store områder af CS, hvor ASTer bruges.
- Lisp-sprog er faktisk skrevet som AST. Programmets kildekode skrives som lister og bruges direkte af kompilatoren og / eller tolken (afhængigt af hvilken variant der bruges).
- Modelleringssprog, f.eks. UML, og mange visuelle domænespecifikke sprog bruger grafiske notationer, der er effektive abstrakte syntaksgrafer (ASG) på et højere abstraktionsniveau end det typiske generelle sprog AST.