Ho bisogno di creare un convertitore da Scala in un'altra lingua. Sto cercando un parser di codice di scala che converta il codice in albero di sintassi senza compilazione.Analizzatore di codice Scala (non compilatore)
Lasciatemi fare in modo semplice: non c'è modo di generare un AST del programma Scala con parser da solo. È assolutamente necessario eseguire il typer, e questo significa inferire tipo e impliciti.
Dopodiché, puoi fare quello che vuoi. Ma queste prime poche fasi del compilatore (quattro sulle versioni più recenti, contando il typer) sono necessarie.
Per coincidenza, si tratta delle fasi eseguite dallo presentation compiler, che viene utilizzato dallo Scala IDE for Eclipse. Mi sembra che questa potrebbe essere l'interfaccia perfetta per te.
ENSIME anche uses it, che sembra essere la migliore fonte di informazioni su di esso, e si potrebbe anche voler dare un'occhiata lo strumento Scala Refactoring, in quanto utilizza AST del compilatore pure.
Infine, puoi provare a compilare il codice con -Ybrowse:typer per vedere l'albero dopo typer. Utilizzare -Xshow-phases per visualizzare le fasi esistenti o -Xprint:typer per stampare la "fonte" dopo typer (o qualsiasi altra fase).
Penso che la tua risposta di base sia fuorviante. Se hai una grammatica, puoi generare un AST; dopotutto, le grammatiche e gli alberi (sintassi) riguardano la pura sintassi. Sono d'accordo, spesso hai bisogno di informazioni sul tipo per interpretare l'AST utilmente. (Non mi oppongo ai tuoi suggerimenti su macchinari utili). –
@Ira Ciò presuppone che la lingua possa essere _parsed_ con una grammatica. Perl, ad esempio, [can not] (http://www.perlmonks.org/?node_id=663393). Su Scala, la giuria è ancora fuori - alcune persone hanno provato a costruire un parser basato sulle specifiche EBNF, ma hanno scoperto che non funziona del tutto. Forse Scala può essere analizzato da una grammatica, ma, in pratica, qualsiasi analisi di questo tipo sarebbe _useless_ senza typer, poiché parte del codice sorgente viene fornita implicitamente da quella fase. –
Anche questa stessa storia è stata raccontata di C++. È sbagliato. Ciò che è vero è che alcune delle parses possono essere ambigue localmente. Possono anche essere altamente ambigui, localmente. Per lo più, ciò significa che la tecnologia di analisi utilizzata dalle persone (LL (k) e LALR (1)) è piuttosto pessima. Ciò non significa che la giusta tecnologia di analisi sia pessima. Vedi analisi GLR, che gestisce tali ambiguititi con aplomb. Analizziamo il C++ in questo modo nonostante i teoremi popolari riguardo al fatto che sia "difficile". Stiamo lavorando su un parser Perl ma il suo back burner. Ho difficoltà a credere che Scala sia cattiva come Perl. –