Scrivere un compilatore del compilatore: informazioni sull'uso e sulle funzionalità

Questo fa parte di una serie di domande che si concentrano sul progetto gemello del Progetto Abstraction, che mira a sottrarre i concetti utilizzati nella progettazione del linguaggio sotto forma di un quadro. Il progetto gemello si chiama OILexer, che mira a costruire un parser da file grammaticali, senza l'uso dell'iniezione di codice sulle partite.

Alcune altre pagine associate a queste domande, relative alla tipizzazione strutturale, possono essere visualizzate qui e facilità d'uso, trovate qui . Il meta-argomento associato a una richiesta di informazioni sul framework e il luogo adatto per la pubblicazione è disponibile qui .

Sto arrivando al punto in cui sto per iniziare a estrarre l'albero di analisi da una determinata grammatica, seguito da un parser di Discesa ricorsiva che utilizza DFA per discernere i percorsi in avanti (simile a LL (*) di ANTLR 4, quindi I ho pensato di aprirlo per ottenere informazioni.

In un compilatore parser, quali tipi di funzionalità sono ideali?

Finora ecco una breve panoramica di ciò che è implementato:

1. Modelli
2. Guarda avanti la previsione, sapendo cosa è valido in un determinato punto.
3. Regola la "deliteralizzazione" prendendo i letterali all'interno delle regole e risolvendo da quale token provengono.
4. Automi non deterministici
5. Automi deterministici
6. Semplice macchina a stati lessicali per il riconoscimento di token
7. Metodi di automazione dei token:
   • Scansione: utile per i commenti: Commento: = "/ *" Scansione ("* /");
   • Sottrai - Utile per gli identificatori: Identificatore: = Sottrai (IdentifierBody, Parole chiave);
     • Assicura che l'identificatore non accetta le parole chiave.
   • Codifica: codifica un'automazione come conteggio serie X di transizioni N base.
     • UnicodeEscape: = "\\ u" BaseEncode (IdentifierCharNoEscape, 16, 4);
       • Fa una fuga unicode in esadecimale, con 4 transizioni esadecimali. La differenza tra questo e: [0-9A-Fa-f] {4} è che l'automazione risultante con Encode limita l'insieme consentito di valori esadecimali all'ambito di IdentifierCharNoEscape. Quindi se lo dai \ u005c, la versione della codifica non accetterà il valore. Cose come questa hanno un serio avvertimento: usare con parsimonia. L'automazione risultante potrebbe essere piuttosto complessa.

Ciò che non è implementato è la generazione CST, ho bisogno di regolare le automazioni deterministiche per riportare il contesto adeguato per farlo funzionare.

Per chiunque sia interessato, ho caricato una bella stampa della forma originale del progetto T * y♯ . Ogni file dovrebbe collegarsi ad ogni altro file, ho iniziato a collegare le singole regole per seguirli, ma ci sarebbe voluto troppo tempo (sarebbe stato più semplice automatizzare!)

Se è necessario più contesto, si prega di pubblicare di conseguenza.

Modifica 5-14-2013 : ho scritto codice per creare grafici GraphViz per le macchine a stati in una determinata lingua. Ecco un digraph GraphViz di AssemblyPart . I membri collegati nella descrizione della lingua dovrebbero avere un ruleename.txt nella loro cartella relativa con il digraph per quella regola. Parte della descrizione della lingua è cambiata da quando ho pubblicato l'esempio, ciò è dovuto alla semplificazione delle cose sulla grammatica. Ecco un'interessante immagine di graphviz .

Questa è un'ottima domanda

Ho lavorato su un sacco di analisi di recente e IMHO alcune delle caratteristiche principali sono:

• un'API programmatica - quindi può essere utilizzata all'interno di un linguaggio di programmazione, idealmente semplicemente importando una libreria. Può avere anche una GUI o un'interfaccia simile a BNF, ma quella programmatica è la chiave, perché puoi riutilizzare i tuoi strumenti, IDE, analisi statica, test, strutture di astrazione del linguaggio, familiarità del programmatore, generatore di documentazione, processo di compilazione, ecc. Inoltre, puoi giocare interattivamente con piccoli parser, il che riduce drasticamente la curva di apprendimento. Questi motivi lo collocano in cima al mio elenco di "caratteristiche importanti".

• segnalazione errori, come menzionato da @guysherman. Quando viene rilevato un errore, voglio sapere dove si trovava l'errore e cosa stava succedendo quando si è verificato. Sfortunatamente, non sono stato in grado di trovare buone risorse per spiegare come generare errori decenti quando entra in gioco il backtracking. (Anche se nota il commento di @ Sk-logic di seguito).

• risultati parziali. Quando l'analisi non riesce, voglio essere in grado di vedere cosa è stato analizzato correttamente dalla parte dell'input che era prima della posizione dell'errore.

• astrazione. Non puoi mai integrare abbastanza funzioni e l'utente avrà sempre bisogno di più, quindi cercare di capire tutte le possibili funzioni in anticipo è destinato a fallire. È questo che intendi per modelli?

• Sono d'accordo con la tua # 2 (previsione del futuro). Penso che aiuti a generare buoni rapporti sugli errori. È utile per qualcos'altro?

• supporto per la creazione di un albero di analisi quando si verifica l'analisi, forse:

  • un albero di sintassi concreto, per il quale la struttura dell'albero corrisponde direttamente alla grammatica e include informazioni di layout per la segnalazione degli errori delle fasi successive. In questo caso, il client non dovrebbe fare nulla per ottenere la giusta struttura ad albero - dovrebbe dipendere direttamente dalla grammatica.
  • un albero di sintassi astratto. In questo caso, l'utente è in grado di giocherellare con qualsiasi e tutti gli alberi di analisi

• una specie di registrazione. Non ne sono sicuro; magari per mostrare una traccia delle regole che il parser ha provato, o per tenere traccia dei token spazzatura come spazi bianchi o commenti, nel caso (per esempio) si vogliano usare i token per generare documentazione HTML.

• capacità di trattare lingue sensibili al contesto. Non sono sicuro di quanto sia importante questo - in pratica, sembra più pulito analizzare un superset di una lingua con una grammatica senza contesto, quindi controllare i vincoli sensibili al contesto in ulteriori passaggi successivi.

• messaggi di errore personalizzati, in modo da poter ottimizzare le segnalazioni di errori in situazioni specifiche e forse comprendere e risolvere più rapidamente i problemi.

D'altra parte, non trovo la correzione degli errori particolarmente importante, anche se non sono aggiornato sui progressi attuali. I problemi che ho notato sono che le potenziali correzioni fornite dagli strumenti sono: 1) troppo numerose e 2) non corrispondono agli errori effettivi commessi, quindi non sono poi così utili. Speriamo che questa situazione migliorerà (o forse lo abbia già fatto).

Non ho esperienza nella progettazione del linguaggio, ma una volta ho provato a scrivere un parser, mentre creavo e IDE per un motore di gioco.

Qualcosa che è importante per i tuoi utenti finali finali, a mio avviso, sono i messaggi di errore che hanno senso. Non un punto particolarmente sconvolgente, lo so, ma seguendolo al contrario, una delle implicazioni chiave di questo è che devi essere in grado di evitare falsi positivi. Da dove vengono i falsi positivi? Provengono dal parser che cade al primo errore e non si riprende mai del tutto. C / C ++ è noto per questo (anche se i compilatori più recenti sono un po 'più intelligenti).

Allora cosa ti serve? Penso che piuttosto che sapere cosa è / non è valido in un determinato momento, devi sapere come prendere ciò che non è valido e apportare una modifica minima per renderlo valido - in modo da poter continuare ad analizzare senza generare falsi errori relativi alla tua discesa ricorsiva confondendoti. Essere in grado di costruire un parser in grado di generare queste informazioni non solo ti dà un parser molto robusto, ma apre alcune fantastiche funzionalità per il software che consuma il parser.

Mi rendo conto che potrei suggerire qualcosa di veramente difficile, o stupidamente ovvio, scusami se è così. Se questo non è il genere di cose che stai cercando, eliminerò felicemente la mia risposta.

La grammatica non deve avere restrizioni come "non hanno lasciato regole ricorsive". È ridicolo che gli strumenti ampiamente utilizzati oggi abbiano questo e possano capire solo succhiare le grammatiche LL - quasi 50 anni dopo che yacc ha fatto bene.

Un esempio per la corretta ricorsione (usando la sintassi yacc):

list: 
      elem                  { $$ = singleton($1); }
    | elem ',' list         { $$ = cons($1, $2);  }
    ;

Un esempio per la ricorsione a sinistra (usando la sintassi yacc):

funapp:
    term                    { $$ = $1; }
    | funapp term           { $$ = application($1, $2); }
    ;

Ora, questo potrebbe forse essere "rifattorizzato" a qualcos'altro, ma in entrambi i casi, il tipo specifico di ricorsione è solo il modo "giusto" per scriverlo, poiché gli elenchi (nella lingua di esempio) sono ricorsivi a destra mentre l'applicazione delle funzioni viene lasciata ricorsiva .

Ci si può aspettare da strumenti avanzati che supportano il modo naturale di scrivere le cose, invece di richiedere di "rifattorizzare" tutto ciò che deve essere ricorsivo sinistro / destro dallo strumento su cui si impone.