[SableCC] conoscere l'AST parziale

[dierre]

Mi rendo conto che un long shot chiedere qui (di solito non si parla di parser generator), ma tentare non nuoce.
Con SableCC 3.2 ho implementato un Custom Lexer che mi stampa i token letti fino ad un certo punto. Ecco un esempio:


TId, state : 0, text : [font]
TLPar, state : 0, text : [(]
TBlank, state : 0, text : [ ]
TId, state : 0, text : [arial]
TComma, state : 0, text : [,]
TBlank, state : 0, text : [ ]
TId, state : 0, text : [bold]
TComma, state : 0, text : [,]
TBlank, state : 0, text : [ ]
TNumber, state : 0, text : [20]
TRPar, state : 0, text : [)]
TBlank, state : 0, text : [ ]
TLPar, state : 0, text : [(]
TBlank, state : 0, text : [ ]
TLPar, state : 0, text : [(]
TElement, state : 0, text : [v]
TDot, state : 0, text : [.]
TId, state : 0, text : [degree]
TBlank, state : 0, text : [ ]
TCop, state : 0, text : [>=]
TBlank, state : 0, text : [ ]
TNumber, state : 0, text : [3]
TBlank, state : 0, text : [ ]
TRPar, state : 0, text : [)]
TBlank, state : 0, text : [ ]
TLogicAnd, state : 0, text : [AND]
TBlank, state : 0, text : [ ]
TLogicNot, state : 0, text : [NOT]
TBlank, state : 0, text : [ ]
TElement, state : 0, text : [v]
TDot, state : 0, text : [.]
TId, state : 0, text : [label]
TBlank, state : 0, text : [ ]
TCop, state : 0, text : [==]
TBlank, state : 0, text : [ ]
TString, state : 0, text : ["Roma"]
TBlank, state : 0, text : [ ]
TRPar, state : 0, text : [)]
TBlank, state : 0, text : [ ]
TRPar, state : 0, text : [)]
Parser Exception
[1,71] expecting: EOF


Come potete vedere, siccome l'istruzione è incorretta, il parser genera un'eccezione dicendo dove è sbagliato il codice. Il che mi va benissimo, però il fatto che sia in grado di capire dov'è l'errore implica che sto benedetto AST è parzialmente costruito. Il problema è che il TreeWalker che deriva da un DepthFirstAdapter si attiva solo quando il parser non ha generato errori, io invece vorrei avere comunque accesso all'AST perché in pratica mi serve per colorare la sintassi e in questo caso i vari TId o TNumber che vedete sono in realtà dei parametri, io vorrei avere accesso al padre:


par =
{numero} number |
{stringa} string |
{idpar} id ;

[wingman87]

Ciao, un'idea potrebbe essere quella di costruire "manualmente" l'albero all'interno delle produzioni. In ogni caso mi chiedo se sia questa la soluzione adottata dai vari IDE per il syntax highlighting in quando interrompendo la parsificazione al primo errore avrai una prima parte colorata e la seconda no (nel tuo esempio specifico in realtà no perché hai raggiunto EOF). Forse dovresti spezzare la grammatica in più sottoinsiemi disgiunti, ovviamente con una perdita di informazione, e parsificare più volte il codice per colorare una porzione per volta, ma non so se è fattibile, non ho mai fatto nulla del genere.
In ogni caso io non ho mai usato SableCC ma solo JavaCC ma credo siano simili...

[dierre]

Ciao, un'idea potrebbe essere quella di costruire "manualmente" l'albero all'interno delle produzioni. In ogni caso mi chiedo se sia questa la soluzione adottata dai vari IDE per il syntax highlighting in quando interrompendo la parsificazione al primo errore avrai una prima parte colorata e la seconda no (nel tuo esempio specifico in realtà no perché hai raggiunto EOF). Forse dovresti spezzare la grammatica in più sottoinsiemi disgiunti, ovviamente con una perdita di informazione, e parsificare più volte il codice per colorare una porzione per volta, ma non so se è fattibile, non ho mai fatto nulla del genere.
In ogni caso io non ho mai usato SableCC ma solo JavaCC ma credo siano simili...

Infatti ti spiego subito come ho fatto al momento:

spezzo il testo in "Istruzioni", essenzialmente l'elemento minimo affinché il parser possa valutare completamente. A quel punto faccio l'analisi Istruzioni per Istruzione (nel mio caso la fine istruzione è "\n"), il lexer cicla ad ogni key pressed mentre il parser cicla ad ogni \n, gli passo un secondo giro di colore :asd:

funziona, però mi stavo domandandavo appunto se potevo comunque analizzare l'albero parziale lo stesso. Ovviamente a quel punto sfrutterei solo quello che ha già costruito, è ovvio che la colorazione corretta si ha a fine istruzione.

[wingman87]

Infatti ti spiego subito come ho fatto al momento:

spezzo il testo in "Istruzioni", essenzialmente l'elemento minimo affinché il parser possa valutare completamente. A quel punto faccio l'analisi Istruzioni per Istruzione (nel mio caso la fine istruzione è "\n"), il lexer cicla ad ogni key pressed mentre il parser cicla ad ogni \n, gli passo un secondo giro di colore :asd:
Ma quindi il parser che hai scritto valuta solo una singola istruzione? Non valuti il testo nell'insieme? E' più o meno quello che intendevo io, anche se pensavo a una cosa meno radicale: ad esempio un parser per riconoscere le dichiarazioni di variabili, uno per riconoscere le sequenze di parentesi, uno per la singola istruzione come mi pare di capire che hai fatto tu, ecc. Poi non so per quale linguaggio stai scrivendo il parser...

funziona, però mi stavo domandandavo appunto se potevo comunque analizzare l'albero parziale lo stesso.
Credo di sì, alla peggio dovresti inserire delle istruzioni nelle produzioni per creare un secondo albero di sicurezza da sfruttare nel caso in cui la parsificazione termina prematuramente, ma secondo me potrebbe anche esserci una impostazione di SableCC che ti permette di dire che vuoi ottenere l'AST anche se non è completo.
Ovviamente a quel punto sfrutterei solo quello che ha già costruito, è ovvio che la colorazione corretta si ha a fine istruzione.
Io in verità immaginavo un caso in cui invece di scrivere volta per volta aggiungendo al fondo vai anche a fare delle modifiche in mezzo al codice, in quel caso se si verificano degli errori tutta la parte dopo l'istruzione che hai aggiunto perde la colorazione. Ovviamente se parsifichi separatamente ogni istruzione e non il testo nell'insieme non c'è problema.

[dierre]

Ma quindi il parser che hai scritto valuta solo una singola istruzione? Non valuti il testo nell'insieme? E' più o meno quello che intendevo io, anche se pensavo a una cosa meno radicale: ad esempio un parser per riconoscere le dichiarazioni di variabili, uno per riconoscere le sequenze di parentesi, uno per la singola istruzione come mi pare di capire che hai fatto tu, ecc. Poi non so per quale linguaggio stai scrivendo il parser...

è un linguaggio che usano nel mio dipartimento, è la mia tesi di laurea. Non ha dichiarazioni di variabili. Capisco cosa intendi tu, come fa anche l'editor di eclipse che divide in partizioni. Non è così complesso quindi l'unica partizione è quella dell'istruzione.


Credo di sì, alla peggio dovresti inserire delle istruzioni nelle produzioni per creare un secondo albero di sicurezza da sfruttare nel caso in cui la parsificazione termina prematuramente, ma secondo me potrebbe anche esserci una impostazione di SableCC che ti permette di dire che vuoi ottenere l'AST anche se non è completo.

Ho scoperto che posso implementare il metodo filter che mi permette di lavorare su ogni nodo al momento. Adesso vedo se posso fare qualcosa con quello.


Io in verità immaginavo un caso in cui invece di scrivere volta per volta aggiungendo al fondo vai anche a fare delle modifiche in mezzo al codice, in quel caso se si verificano degli errori tutta la parte dopo l'istruzione che hai aggiunto perde la colorazione. Ovviamente se parsifichi separatamente ogni istruzione e non il testo nell'insieme non c'è problema.

In pratica faccio così: per ogni key press prendi la posizione del cursore. Prendi lo \n precedente e quello successivo alla posizione e parla la singola istruzione.