Cosa ne pensi di un interprete scritto in Java? [chiuso]

Question

Cosa ne pensi di un interprete scritto in Java? [chiuso]

#1 da (5 voti)
#2 da (3 voti)

4

Attualmente sto lavorando all'implementazione di un nuovo linguaggio di programmazione, per divertimento. Mi rendo conto che la maggior parte delle lingue non diventano mai popolari, ma voglio comunque che il linguaggio abbia un'implementazione di alta qualità. Il linguaggio è vagamente lisp-like. Supporta chiusure, continuazioni di prima classe, una sintassi omoiconica, funzioni di prima classe, ecc. Inoltre, voglio che il mio linguaggio sia in grado di accedere a un codice di libreria già stabilito (in particolare la libreria Java standard, ecc.)

La compilazione dinamica in codice byte JVM è essenzialmente fuori questione, a causa della difficoltà di implementare il set di funzionalità dichiarato (escluse le funzioni di prima classe) utilizzando una macchina virtuale che non è progettata per supportarlo. D'altro canto, la compilazione in C / C ++ o qualche altro linguaggio di livello inferiore porterà ad un grado indesiderato di dipendenza dalla piattaforma e / o ridurrà / rimuoverà la possibilità di utilizzare la libreria standard Java tramite programmi scritti nella mia lingua. / p>

Il mio approccio (in gran parte completato) all'implementazione consiste nell'implementare un interprete di p-code personalizzato in Java. Il linguaggio di alto livello semplicemente compila il suo codice al volo essenzialmente su una serie di istruzioni per questa macchina virtuale personalizzata. Ogni istruzione è un oggetto che implementa un'interfaccia comune. Quando vengono eseguite, le istruzioni manipolano una macchina stack. Sfortunatamente, l'esecuzione di ogni istruzione richiede una chiamata al metodo virtuale; mentre la normale implementazione di tali interpreti non utilizza istruzioni basate su oggetti. Tuttavia, gli attuali micro-benchmark e le stime basate su ipotesi indicano che l'implementazione completata dovrebbe corrispondere alla velocità di Python, dati i programmi equivalenti.

Quindi pensi che questo metodo di implementazione sia pazzesco o amatoriale, visti gli obiettivi di progettazione della lingua?

Che cosa faresti in modo diverso?

java language-design interpreters virtual-machine

posta Mackenzie 21.04.2011 - 07:01

fonte

2 risposte

5

Dynamically compiling to JVM byte-code is essentially out of the question, because of the difficulty of implementing the stated feature set (excluding first-class functions) using a virtual machine that is not designed to support it.

Ci sono molti linguaggi che supportano la maggior parte delle funzionalità che descrivi già che compongono in codice byte JVM (JRuby, Scala, Clojure). Le implementazioni di queste lingue sono open-source, quindi consiglierei di studiare il loro approccio nell'implementazione di queste funzionalità sulla JVM.

Ma dal momento che il tuo obiettivo dichiarato è divertente, posso immaginare che guardare attraverso l'implementazione del compilatore di altre lingue non sia qualcosa con cui vuoi iniziare.

La mia esperienza nell'implementazione di un linguaggio di programmazione sulla JVM è che funzionerà facilmente, ma ha alcuni spigoli, specialmente per quanto riguarda le prestazioni e il consumo di memoria quando usi improvvisamente un po 'di dati in più rispetto a un programma di giocattoli.

risposta data 21.04.2011 - 07:35

fonte

Leggi altre domande sui tag java language-design interpreters virtual-machine

Il PHP-GTK è ampiamente utilizzato? [chiuso] Esiste un modello di processo simile al processo a cascata, ma con più cicli?

score 3 · Accepted Answer

Ciò che proponi sembra un approccio generalmente valido. L'oggetto-per-istruzione potrebbe essere un po 'pesante, ma non c'è motivo per cui non si possa iniziare, specialmente se è un progetto facile con cui lavorare.

Sebbene tu suggerisca che la compilazione in bytecode sia fuori questione al momento, è qualcosa che puoi sempre decidere di aggiungere in seguito. Puoi avere un ambiente di runtime che interpreti un po 'di codice e compili il resto (gli ambienti Lisp lo hanno fatto per sempre, e i compilatori JIT continuano a farlo oggi).

Ricorda che può esserci sempre più di un'implementazione linguistica. C ++ è stato implementato per la prima volta come Cfront, un preprocessore su C. Le Early JVM hanno sempre interpretato bytecode, ma ora sono quasi tutte JIT. Python ha implementazioni multiple, alcune delle quali possono anche essere compilate sul codice macchina nativo laddove possibile.