Perché non memorizziamo l'albero di sintassi invece del codice sorgente?

Abbiamo molti linguaggi di programmazione. Ogni lingua viene analizzata e la sintassi viene controllata prima di essere tradotta in codice in modo da creare un albero di sintassi astratto (AST).

Abbiamo questo albero di sintassi astratto, perché non archiviamo questo albero di sintassi invece del codice sorgente (o accanto al codice sorgente)?

Usando un AST invece del codice sorgente. Ogni programmatore di un team può serializzare questo albero in qualsiasi lingua (con la grammatica libera del contesto appropriato) e tornare ad AST al termine. Quindi questo eliminerebbe il dibattito sulle domande sullo stile di codifica (dove mettere {e}, dove mettere spazi bianchi, rientri, ecc.)

Quali sono i pro e i contro di questo approccio?

Spazio bianco e commenti

Generalmente un AST non include spazi bianchi, terminatori di riga e commenti.

Formattazione significativa

Hai ragione nel dire che nella maggior parte dei casi questo è positivo (elimina la formattazione delle guerre sante), ci sono molti casi in cui la formattazione del codice originale trasmette un significato, come nei letterali a più righe e nei "paragrafi di codice" (blocchi separati di istruzioni con una riga vuota).

Codice che non può essere compilato

Mentre molti parser sono molto resistenti alla sintassi mancante, il codice con errori spesso si traduce in un albero di sintassi molto strano, che va bene e dandy fino al punto in cui l'utente ricarica il file. Hai mai fatto un errore nel tuo IDE e poi all'improvviso l'intero file ha "squigglies"? Immagina come sarebbe ricaricato in un'altra lingua.

Forse gli utenti non commettono codice non analizzabile, ma certamente hanno bisogno di salvare localmente.

Non ci sono due lingue che corrispondono perfettamente

Come altri hanno sottolineato, non ci sono quasi due lingue con una perfetta parità di funzionalità. Il più vicino che posso pensare è VB e C #, o JavaScript e CoffeeScript, ma anche allora VB ha caratteristiche come i letterali XML che non hanno abbastanza equivalenti in C #, e la conversione da JavaScript a CoffeeScript potrebbe comportare molti letterali JavaScript.

In un'applicazione software che scrivo, dobbiamo effettivamente farlo, poiché ci si aspetta che gli utenti inseriscano espressioni "semplici inglesi" che vengono convertite in JS in background. Abbiamo considerato solo l'archiviazione della versione JS, ma abbiamo trovato quasi nessun modo accettabile per farlo caricato e scaricato in modo affidabile, quindi abbiamo finito per archiviare sia il testo dell'utente che la versione JS, nonché un flag che indicava se il "semplice inglese "versione analizzata perfettamente o no.

Perché non memorizziamo questo albero di sintassi invece del codice sorgente? Ogni programmatore in una squadra può serializzare questo albero in qualsiasi lingua, desidera e analizzare AST al termine.

In effetti, questa è un'idea ragionevole. Microsoft ha avuto un progetto di ricerca negli anni '90 per fare quasi esattamente questo .

Vengono in mente diversi scenari.

Il primo è piuttosto banale; come dici tu, potresti avere l'AST renderizzato in viste diverse a seconda delle preferenze dei diversi programmatori per cose come la spaziatura e così via. Ma la memorizzazione di un AST è eccessiva per quello scenario; scriviti una bella stampante. Quando carichi un file nel tuo editor, esegui pretty-printer per metterlo nel formato che preferisci e poi nel formato originale quando lo salvi.

Il secondo è più interessante. Se riesci a memorizzare l'albero di sintassi astratto, la modifica del codice non diventa testuale ma piuttosto sintattica. I refactoring in cui il codice viene spostato diventano molto più facili da capire. Il rovescio della medaglia è ovviamente che scrivere gli algoritmi di diff albero non è esattamente banale e spesso deve essere fatto in base alla lingua. La diff di testo funziona per quasi tutte le lingue.

Il terzo è più simile a quello che Simonyi ha immaginato per la Programmazione intenzionale: che i concetti fondamentali comuni ai linguaggi di programmazione sono quelli che sono serializzati, e quindi si hanno diverse visioni di quei concetti resi in linguaggi diversi. Sebbene sia una bella idea, il fatto brutto è che le lingue sono sufficientemente diverse nei loro dettagli che un approccio dal minimo comune denominatore non funziona davvero.

Quindi, in breve, è una bella idea ma è un'enorme quantità di lavoro extra per un vantaggio relativamente piccolo. Ecco perché quasi nessuno lo fa.

Si potrebbe sostenere che questo è esattamente ciò che il codice byte è in .NET. Infatti il ​​programma riflettore di redgate traduce nuovamente il codice byte in una gamma di linguaggi di programmazione .NET.

Tuttavia, ci sono problemi. La sintassi è specifica della lingua in quanto ci sono cose che puoi rappresentare in una lingua che non hanno rappresentazione in altre lingue. Ciò si verifica in .NET con C ++ che è l'unico linguaggio .NET che ha accesso a tutti e 7 i livelli di accesso.

Al di fuori dell'ambiente .NET diventa molto più complicato. Ogni lingua quindi inizia ad avere il proprio set di librerie associate. Non sarebbe possibile riflettere una sintassi generica in C e Java che riflettesse la stessa esecuzione di istruzioni in quanto risolvono problemi simulati in modi molto diversi.

In qualche modo mi piace la tua idea, ma stai sopravvalutando in modo significativo quanto sia facile tradurre la lingua in lingua. Se fosse così facile, non avresti nemmeno bisogno di memorizzare l'AST, dato che potresti sempre analizzare la lingua X nell'AST, quindi passare dall'AST alla lingua Y.

Tuttavia, vorrei che le specifiche del compilatore pensassero un po 'di più sull'esposizione di alcune AST attraverso un qualche tipo di API. Cose come la programmazione orientata all'aspetto, il refactoring e l'analisi del programma statico potrebbero essere implementate attraverso una tale API, senza che l'implementatore di quelle capacità debba rifare gran parte del lavoro già implementato dagli autori di compilatori.

È strano quanto spesso la struttura dei dati del programmatore per rappresentare un programma sia come un mucchio di file contenenti stringhe.

Penso che i punti più salienti siano quelli:

• Non ci sono benefici Hai detto che avrebbe significato che tutti potevano usare il loro linguaggio da compagnia. Ma non è vero : l'uso di una rappresentazione ad albero di sintassi eliminerebbe solo le differenze sintattiche, ma non quelle semantiche. Funziona in una certa misura per linguaggi molto simili - come VB e C #, o Java e Scala. Ma nemmeno lì del tutto.

• È problematico. Hai acquisito la libertà di linguaggio, ma hai perso la libertà di strumenti. Non è più possibile leggere e modificare il codice in un editor di testo o in qualsiasi IDE: si dipende da uno strumento specifico che parla la propria rappresentazione AST sia per leggere che per modificare il codice. Non c'è niente guadagnato qui.

  Per illustrare quest'ultimo punto, dai un'occhiata a RealBasic, che è un'implementazione proprietaria di un potente dialetto BASIC. Per un po ', sembrava quasi che la lingua potesse decollare, ma dipendeva completamente dal fornitore, al punto che era possibile visualizzare solo il codice nel loro IDE poiché era stato salvato in un formato proprietario non testuale. Grande errore.

Penso che, se memorizzi sia il testo che l'AST, non hai aggiunto nulla di veramente utile, poiché il testo è già lì in una lingua e l'AST può essere rapidamente ricostruito dal testo.

D'altra parte, se memorizzi solo l'AST, perdi cose come commenti che non possono essere recuperati.

Credo che l'idea sia interessante in teoria ma non molto pratica poiché diversi linguaggi di programmazione supportano costrutti diversi alcuni che non hanno equivalenti in altri linguaggi.

Ad esempio, X ++ ha un'istruzione 'while select' che non può essere scritta in C # senza molto codice aggiuntivo (classi extra, logica extra, ecc.). http://msdn.microsoft.com/en-us/library/aa558063.aspx

Quello che sto dicendo qui è che molte lingue hanno zuccheri sintattici che si traducono in grandi blocchi di codice della stessa lingua o addirittura in elementi che non esistono affatto negli altri. Ecco un esempio del perché l'approccio AST non funzionerà:

La lingua X ha una parola chiave K tradotta, in AST in 4 istruzioni: S1, S2, S3 e S4. L'AST viene ora tradotto nella lingua Y e un programmatore cambia S2. Cosa succede ora con la traduzione in X? Il codice viene tradotto come 4 istruzioni anziché una singola parola chiave ...

L'ultimo argomento contro l'approccio AST sono le funzioni della piattaforma: cosa succede quando una funzione è incorporata nella piattaforma? Come Environment.GetEnvironmentVariable di .NET. Come lo traduci?

C'è un sistema costruito attorno a questa idea: JetBrains MPS . Un editor è un po 'strano, o semplicemente diverso, ma in generale non è un grosso problema. Il problema più grande è, beh, che non si tratta di un testo più, quindi non è possibile utilizzare uno dei normali strumenti basati su testo - altri editori, grep, sed, di fusione e differenze attrezzi, ecc

Esistono in realtà diversi prodotti, generalmente noti come "banchi di lavoro linguistici" che memorizzano gli AST e presentano, nei loro redattori, una "proiezione" dell'AST in una lingua particolare. Come diceva @ sk-logic, l'MPS di JetBrains è uno di questi sistemi. Un altro è Intentional Software's Intentional Workbench.

Il potenziale per i banchi di lavoro linguistici sembra molto elevato, in particolare nell'area delle lingue specifiche del dominio, poiché è possibile creare una proiezione specifica del dominio. Ad esempio, Intentional dimostra un DSL relativo all'elettricità che si proietta come uno schema circuitale - molto più facile e più preciso per un esperto di dominio da discutere e criticare rispetto a un circuito descritto in un linguaggio di programmazione basato su testo.

In pratica, i banchi di lavoro linguistici sono stati lenti a prendere piede perché, a parte il lavoro DSL, gli sviluppatori preferirebbero probabilmente lavorare in un linguaggio di programmazione familiare e generale. Se confrontati testa a testa con un editor di testo o un IDE di programmazione, i banchi di lavoro linguistici hanno un sacco di costi generali e i loro vantaggi non sono altrettanto chiari. Nessuno dei banchi di lavoro linguistici che ho visto si è legato al punto da poter estendere facilmente i propri IDE, ovvero se i banchi di lavoro linguistici sono ottimi per la produttività, perché gli strumenti del banco di lavoro linguistici non migliorano -e-meglio a tassi sempre più veloci?

Mi hai letto nella mente.

Quando ho seguito un corso per compilatori, qualche anno fa, ho scoperto che se prendi un AST e lo serializzi, con la notazione prefisso invece della solita notazione infix, e usi le parentesi per delimitare intere dichiarazioni, ottieni Lisp. Mentre avevo imparato a conoscere Scheme (un dialetto di Lisp) nei miei studi universitari, non avevo mai veramente apprezzato. Ho sicuramente guadagnato un apprezzamento per Lisp e i suoi dialetti, come risultato di quel corso.

Problemi con ciò che proponi:

1. è difficile / lento comporre un AST in un ambiente grafico. Dopotutto, molti di noi possono digitare più velocemente di quanto possiamo spostare un mouse. Eppure, una domanda emergente è "come si scrive il codice del programma con un tablet?" Digitare su un tablet è lento / ingombrante, rispetto a una tastiera / laptop con una tastiera hardware. Se potessi creare un AST trascinando e rilasciando componenti da una tavolozza su una tela su un grande dispositivo touchscreen, la programmazione su un tablet potrebbe diventare una cosa reale.

2. pochi / nessuno dei nostri strumenti esistenti supporta questo. Abbiamo decenni di sviluppo legati alla creazione di IDE sempre più complessi e di editor sempre più intelligenti. Abbiamo tutti questi strumenti per riformattare il testo, confrontare il testo, cercare il testo. Dove sono gli strumenti che possono fare l'equivalente di una ricerca di espressioni regolari attraverso un albero? O un diff di due alberi? Tutte queste cose possono essere facilmente eseguite con il testo. Ma possono solo confrontare le parole. Cambia un nome di variabile, in modo che le parole siano diverse ma il significato semantico sia lo stesso, e quegli strumenti diff si mettono nei guai. Tali strumenti, sviluppati per operare su AST anziché su testo, ti permetterebbero di avvicinarti al confronto del significato semantico. Sarebbe una buona cosa.

3. mentre trasformare il codice sorgente del programma in un AST è relativamente ben compreso (abbiamo compilatori e interpreti, vero?), trasformare un AST in un codice di programma non è così ben compreso. Moltiplicare due numeri primi per ottenere un numero composto elevato è relativamente semplice, ma è molto più difficile includere un numero composto elevato in numeri primi; ecco dove siamo con l'analisi e la decompilazione degli AST. Ecco dove le differenze tra le lingue diventano un problema. Anche all'interno di una lingua particolare, esistono diversi modi per decompilare un AST. Scorrere una raccolta di oggetti e ottenere un tipo di risultato, ad esempio. Utilizzare un ciclo for, iterando attraverso un array? Sarebbe compatto e veloce, ma ci sono delle limitazioni. Usa un Iteratore di qualche tipo, operando in una collezione? Quella raccolta potrebbe essere di dimensioni variabili, il che aumenta la flessibilità a (possibile) spesa della velocità. Riduci mappa? Più complesso, ma implicitamente parallelizzabile. E questo è solo per Java, a seconda delle tue preferenze.

Con il tempo, lo sforzo di sviluppo sarà speso e svilupperemo utilizzando touchscreen e AST. La digitazione diventerà meno necessaria. Vedo che come una progressione logica da dove siamo, osservando come usiamo i computer, oggi, ciò risolverà il n. 1.

Stiamo già lavorando con gli alberi. Lisp è semplicemente AST serializzato. XML (e HTML, per estensione) è solo un albero serializzato. Per effettuare la ricerca, abbiamo già un paio di prototipi: XPath e CSS (rispettivamente per XML e HTML). Quando vengono creati strumenti grafici che ci consentono di creare selettori e modificatori in stile CSS, avremo risolto parte del n. 2. Quando quei selettori possono essere estesi per supportare regex, saremo più vicini. Ancora alla ricerca di un buon strumento grafico diff per confrontare due documenti XML o HTML. Man mano che le persone sviluppano questi strumenti, sarà possibile risolvere il n. 2. Le persone stanno già lavorando su tali cose; semplicemente non ci sono ancora.

L'unico modo in cui posso vedere per essere in grado di decompilare gli AST nel testo del linguaggio di programmazione sarebbe una ricerca di obiettivi. Se sto modificando il codice esistente, l'obiettivo potrebbe essere raggiunto da un algoritmo che rende il mio codice modificato il più simile possibile al codice iniziale (minima differenza testuale). Se sto scrivendo codice da zero, l'obiettivo potrebbe essere il codice più piccolo e stretto (probabilmente un ciclo for). Oppure potrebbe essere il codice che si parallelizza nel modo più efficiente possibile (probabilmente una mappa / riduzione o qualcosa che coinvolge CSP). Pertanto, lo stesso AST potrebbe comportare un codice significativamente diverso, anche nella stessa lingua, in base al modo in cui gli obiettivi sono stati fissati. Lo sviluppo di un tale sistema risolverebbe il n. 3. Sarebbe complesso dal punto di vista computazionale, il che significa che probabilmente avremmo bisogno di una sorta di disposizione client-server,

Se la tua intenzione è quella di eliminare il dibattito sugli stili di formattazione, allora forse quello che vuoi è un editor che legge in un file sorgente, lo formatta secondo le tue preferenze personali per la visualizzazione e la modifica, ma quando lo salva, riformatta lo stile scelto dal team utilizza.

È abbastanza facile se usi un editor come Emacs . La modifica dello stile di formattazione di un intero file è un processo a tre comandi.

Dovresti anche essere in grado di creare hook per trasformare automaticamente un file nel tuo stile durante il caricamento e trasformarlo nello stile di squadra durante il salvataggio.

È difficile leggere e modificare un AST, invece del codice sorgente.

Tuttavia, alcuni strumenti correlati al compilatore consentono di utilizzare l'AST. Il bytecode Java e il codice intermedio .NET funzionano in modo simile a un AST.

è una bella idea; ma l'AST di ogni lingua è diversa dalle altre.

l'unica eccezione che conosco è per VB.NET e C #, in cui Microsoft sostiene che sono "la stessa lingua esatta con sintassi diversa". Anche altri linguaggi .NET (IronPython, F #, qualunque cosa) sono diversi a livello di AST.

La stessa cosa con i linguaggi JVM, tutti hanno come target lo stesso bytecode, ma i costrutti del linguaggio sono diversi, il che lo rende linguaggi diversi e AST diversi.

Perfino i linguaggi 'thin layer', come CoffeScript e Xtend condividono gran parte della teoria dei linguaggi sottostanti (JavaScript e Java, rispettivamente); ma introdurre concetti di livello superiore che sono (o dovrebbero essere) mantenuti a livello di AST.

se Xtend potesse essere ricostruito da un AST Java, penso che sarebbe stato definito un "non compilatore" da Java a Xtend che crea magicamente astrazioni di livello superiore dal codice Java esistente, non credi?