Strumenti di programmazione visiva, perché non funzionano direttamente con l'AST?

Ho trovato diversi strumenti di programmazione visiva open source come Blockly e amici e altri progetti ospitati su Github, ma non sono riuscito a trovare nessuno che funzioni direttamente con l'albero di sintassi astratto.

Perché?

Lo sto chiedendo perché una volta scoperto che ogni compilatore là fuori ha una fase del processo di compilazione in cui analizza il codice sorgente in un AST, era ovvio per me che alcuni strumenti di programmazione visiva potevano trarne vantaggio per fornire ai programmatori modi per modificare l'AST direttamente in modo visivo, e anche per fare il round trip da sorgente a nodo-grafico e poi di nuovo alla sorgente quando necessario.

Ad esempio, si potrebbe pensare che dal JavaScript AST Visualizer a un vero strumento di programmazione visuale JavaSript non ci sia molta differenza.

Quindi, cosa mi sto perdendo?

Molti di questi strumenti fanno lavorare direttamente con l'albero di sintassi astratta (o meglio, una diretta visualizzazione uno-a-uno di esso). Che include Blockley, che hai visto, e le altre lingue e redattori basati su blocchi di simile ( Scratch , matita Codice / Droplet , Snap! , GP , piastrella Grazia , e così via).

Questi sistemi non mostrano una tradizionale rappresentazione grafica dei vertici e dei bordi, per ragioni spiegate altrove (spazio e anche difficoltà di interazione), ma rappresentano direttamente un albero. Un nodo o blocco è figlio di un altro se è direttamente, fisicamente all'interno del genitore.

Ho costruito uno di questi sistemi ( Tiled Grace , carta , carta ). Posso assicurarti che sta lavorando molto direttamente con l'AST: quello che vedi sullo schermo è una rappresentazione esatta dell'albero di sintassi, come elementi DOM nidificati (quindi, un albero!).

Questo è l'AST di alcuni codici. Il root è un nodo di chiamata del metodo "for ... do". Quel nodo ha alcuni figli, che iniziano con "_ .. _", che a sua volta ha due figli, un nodo "1" e un nodo "10". Ciò che appare sullo schermo è esattamente ciò che il backend del compilatore sputa nel mezzo del processo - è fondamentalmente come funziona il sistema.

Se vuoi, puoi pensarlo come un layout ad albero standard con i bordi che puntano fuori dallo schermo verso di te (e occluso dal blocco di fronte a loro), ma l'annidamento è un modo valido per mostrare un albero come un vertice diagramma.

Farà anche "il round trip dall'origine al nodo-grafico e poi di nuovo all'origine quando necessario". In effetti, puoi vedere che succede quando fai clic su "Vista Codice" in basso. Se modifichi il testo, verrà nuovamente analizzato e l'albero risultante verrà reso nuovamente modificabile, e se modifichi i blocchi, la stessa cosa accade con l'origine.

Pencil Code fa essenzialmente la stessa cosa con, a questo punto, un'interfaccia migliore . I blocchi che utilizza sono una vista grafica di AST CoffeeScript. Così fanno gli altri sistemi basati su blocchi o su piastrelle, in generale, sebbene alcuni di essi non rendano l'aspetto di nidificazione altrettanto chiaro nella rappresentazione visiva, e molti non hanno un vero linguaggio testuale dietro di loro, quindi il " albero di sintassi "può essere un po 'illusorio, ma il principio è lì.

Cosa ti manca, poi, è che questi sistemi in realtà stanno lavorando direttamente con l'albero di sintassi astratta. Quello che vedi e manipoli è un rendering efficiente in termini di spazio di un albero, in molti casi letteralmente l'AST produce un compilatore o un parser.

Almeno due motivi:

1. Perché il codice sorgente è una rappresentazione molto più concisa. Disporre un AST come un grafico richiederebbe molto più spazio visivo.

   I programmatori premiano il maggior numero possibile di contesti, ovvero la presenza di più codici contemporaneamente sullo schermo contemporaneamente. Il contesto li aiuta a gestire meglio la complessità. (Questo è uno dei motivi per cui molti programmatori usano questi piccoli caratteri folli e enormi schermi da 30 ".)

   Se provassimo a visualizzare l'AST come un grafico o un albero, la quantità di codice che potresti adattare su una singola schermata sarebbe molto inferiore rispetto a quando viene rappresentata come codice sorgente. Questa è una perdita enorme per la produttività degli sviluppatori.

2. Gli AST sono destinati alla programmazione del compilatore, non per una facile comprensione da parte dei programmatori. Se prendessi una rappresentazione AST esistente e la visualizzassi visivamente, probabilmente sarebbe più difficile da capire per gli sviluppatori, perché gli AST non sono stati progettati per essere facili da imparare per gli sviluppatori.

   Al contrario, il codice sorgente di solito è progettato per essere leggibile / comprensibile dagli sviluppatori; questo è normalmente un criterio di progettazione critico per il codice sorgente, ma non per gli AST. Gli AST devono essere compresi solo dagli autori del compilatore, non dagli sviluppatori di tutti i giorni.

   E, in ogni caso, la lingua AST sarebbe una seconda lingua che gli sviluppatori devono imparare, oltre alla lingua di partenza. Non una vittoria.

Vedi anche /software//q/119463/34181 per alcuni potenziali motivi aggiuntivi.

La tipica AST dei compilatori è piuttosto complessa e dettagliata. La rappresentazione del grafico diretto diventerebbe rapidamente piuttosto difficile da seguire. Ma ci sono due grandi aree di CS in cui vengono utilizzati gli AST.

1. Le lingue Lisp sono in realtà scritte come AST. Il codice sorgente del programma viene scritto come elenchi e utilizzato direttamente dal compilatore e / o dall'interprete (a seconda della variante utilizzata).
2. I linguaggi di modellazione, ad esempio UML, e molti linguaggi specifici del dominio visivo utilizzano notazioni grafiche che sono efficaci grafici di sintassi astratti (ASG) a un livello di astrazione più elevato rispetto al tipico linguaggio di uso generale AST.