Loop Unfolding e Named Significant Bits

2

Ho scritto un compilatore Parser per gli ultimi sette anni e recentemente sono arrivato al punto (ancora una volta, mai soddisfatto) di strutturare la parte che si occupa delle parti del linguaggio che sono valide in ogni dato punto.

In altri compilatori di parser, li ho visti utilizzando gli array criptici byte / int che fanno riferimento alle transizioni di stato o a ciò che è valido in un contesto successivo o che cosa hai. Non sono molto appassionato di "numeri magici" che hanno senso per una macchina a stati perché sono convinto che loro (gli array di byte) non siano di grande aiuto durante il debug (almeno non per me).

Per risolvere questo problema, prevedo che una determinata lingua utilizzi un struct personalizzato che contiene sottoinsiemi a enumerazioni multiple. Poiché il parser che sto scrivendo mira a utilizzare le regole di predizione del percorso sono presenti anche in questo set predittivo (non rilevante per questa discussione.)

Ho deciso di fare in modo che questa struttura emettesse un metodo 'ToString' appropriato che descrivesse esplicitamente ciò che è valido, usando i termini della lingua originale, se '= >' è valido, mostrerà '= >'.

La domanda inizia qui:

Questo mi porta al problema: in una lingua con 575 simboli diversi (regola / token) questo produce 18 valori a 32 bit o 2 ^ 575 diverse variazioni. Il singolo metodo ToString che risulta è lungo oltre 7000 linee. È effettivamente un ciclo spiegato sul set di elementi che sono possibili. Ho aggiunto in logica per evitare di scavalcare aree in cui è possibile verificare che siano presenti zero opzioni.

C'è un modo migliore per farlo? Potrei semplicemente controllare i valori delle enumerazioni "valide" e concatenarli, ma perde il contesto importante e spesso crea stringhe più lunghe perché OperatorOrPunctuator_LeftShiftAssign | OperatorOrPunctuator_RightShiftAssign | OperatorOrPunctuator_SemiColon è più lungo di OperatorOrPunctuator ['<<=', '>>=', ';'] .

Ho incluso un link al file in questione , c'è anche un singleton set (la maggior parte dei riferimenti ai simboli nei file collegati sono collegamenti a riferimenti) che verrebbero utilizzati per sperimentare. In cima ai Singletons, io (non ancora fatto) includerò anche una voce per ogni stato all'interno di ogni produzione e previsione della lingua. Questo potrebbe sembrare molto, ma nel calcolare le previsioni per il linguaggio, ci sono attualmente 5.233.421 confronti fatti (unione, differenza simmetrica, intersezioni, eccetera), ma solo 24.030 insiemi distinti. Se esegui la matematica, ciò produrrebbe 24,030 * 4 * 18 byte di dati (1.730.160.)

L'obiettivo di questi è fornire un contesto decente quando si verifica un errore di sintassi, penso che potrebbe anche essere possibile generare falsi token di recupero degli errori se il set completo è disponibile. Anche se mi chiedo se sarà necessario scrivere un algoritmo di percorso più breve per determinare quale "ipotesi" usare in un determinato stato.

    
posta Alexander Morou 09.02.2015 - 17:27
fonte

0 risposte

Leggi altre domande sui tag