Interprete futuro in Java

Question

Qui ho trovato un interprete Simple Forth implementato in Java.
Tuttavia non capisco il significato di esso se voglio usarlo?

Quale potrebbe essere il vantaggio dell'interprete Forth:

• Se il codice compilato finale deve essere eseguito dalla JVM è ancora "Byte codice " cosa vorremmo il Forth L'interprete sta facendo?
• Aiuterà per iscritto programmi efficienti / rigorosi?
• Scriverò il mio codice in avanti e l'interprete lo convertirà a Java?

I tuoi pensieri ...

Answer 1

  

Aiuterà per iscritto   programmi efficienti / rigorosi?

È discutibile.

Sono sicuro che la gente FORTH ti dirà che è veloce. Ma dubito che la velocità di esecuzione di un programma FORTH in esecuzione su un interprete FORTH implementato in Java corrisponderà alla velocità di un programma equivalente implementato direttamente in Java. Per cominciare, il compilatore JIT non sarà in grado di fare un buon lavoro di ottimizzazione dell'interprete FORTH come può per la semplice versione di Java.

Se entro " stretto " intendi "usando meno memoria", penso che la differenza sarà marginale. Ricorda che sia in " FORTH in Java " e "Java semplice" casi hai tutti i sovraccarichi di memoria di una JVM Java. Questo probabilmente sommergerà qualsiasi confronto tra la densità del codice FORTH e la densità equivalente del codice Java compilato.

Answer 2

L'autore nella pagina descrive come implementare un sottoinsieme di FORTH ed essere adatto per essere incorporato in altre applicazioni; presumibilmente ha lo scopo di fornire una capacità di scripting per un'applicazione. È abbastanza improbabile che il sistema funzioni sputando codici byte java o JVM; quasi certamente usa un interprete scritto in Java.

Tradizionalmente, un interprete FORTH può essere implementato in un footprint di memoria molto piccolo. Conosco qualcuno che ne ha implementato uno su un COSMAC e che l'interprete principale era lungo 30 byte . Il codice byte orientato allo stack era anche molto compatto in quanto non era necessario specificare la posizione degli operandi: leggeva semplicemente dallo stack e depositava il risultato nella parte superiore dello stack. Ciò lo ha reso popolare nei circoli di sistemi embedded in cui il piccolo overhead dell'interprete era più che compensato dalla rappresentazione compatta della logica del programma.

Oggigiorno è meno importante poiché le macchine tendono ad essere molto più grandi, anche se digitalross rende un buon punto su altre situazioni in cui FORTH è ancora usato.

Answer 3

Non un traduttore bytecode

Le risposte alle tue domande sono: " vedi sotto, una specie di e nessuna " ;.

È solo un programma che accetta input e produce output. L'input è uno script Forth. Ad eccezione di alcuni sistemi molto importanti, è raro produrre effettivamente bytecode. jRuby, Clojure, Scala .. grandi sistemi del genere producono bytecode.

Tuttavia, probabilmente il tuo interprete Forth è proprio questo: un interprete di script che sembra essere scritto in Java. L'input che accetta è un tipo di programma, quindi si finisce con una bella esecuzione doppia indiretta. Avanti eseguendo tramite l'interprete bytecode eseguendo via jvm in esecuzione sulla CPU.

Ora, se lo avessi eseguito su un emulatore di CPU, o se avessi scritto un interprete in Forth, potresti renderlo triplo-indiretto. (E in un certo senso lo è già, perché la tua CPU Intel sta traducendo la maggior parte degli x86 in codici operativi prima di eseguirli. :-)

Comunque, il punto è che un programma scritto in un linguaggio piuttosto statico come java potrebbe voler prendere un input utente complesso ed eseguirlo, o forse l'autore del programma ha cose che possono essere fatte più facilmente in avanti, e questo gli permette di scrivere sia in java che in avanti.

Dovresti pensare a tutto questo fino a quando non lo capisci.

Answer 4

Ti permette di scrivere programmi efficienti / stretti. In parte perché la capacità di definire le parole di definizione (parole che vengono eseguite in fase di compilazione) può avere l'effetto di definire efficacemente un linguaggio specifico di dominio (DSL). Forth incoraggia anche il refactoring (altrimenti la roba dello stack diventa semplicemente incomprensibile ...) e quindi il codice sarà stretto.

Answer 5

7th è IMHO più vicino al design originale di qualunque altro linguaggio RPN sulla JVM. C'è un editor con numerazione delle righe e codice beautyfier. Esiste un'implementazione corrispondente dell '"interpiler" e il dizionario con vocabolario / corrente / contesto. Condizionalmente la maggior parte delle parole dipendenti dall'hardware & # 8211; per memorizzare o recuperare da un indirizzo di memoria specifico & # 8211; mancano. Qualsiasi parola per calcolare la memoria sulla JVM sarebbe comunque insensata. Alcune utili aggiunte alla quarta sintassi sono state fatte in 7th :

• la parola aiuto
• 7th è orientato agli oggetti
• esiste un perl come il pattern matching
• numeri e matrici complessi fanno parte della lingua
• un meccanismo reindirizzabile / chiudibile per inviare facoltativamente output allo stack o alla console e impedire l'esecuzione di parole file-io, ad es. durante il test

Answer 6

Esistono diversi sistemi Forth che implementano un interprete Forth in Java. Ne conosco due che effettivamente compilano la quarta fonte in una classe JVM e ti permettono di eseguire il codice Forth direttamente senza la necessità dell'interprete.

• HolonJ di Wolf Wejgaard
• Misty Beach Forth

Answer 7

Il vantaggio principale di un interprete FORTH sia la sua interattività - significa che inserisco una parola e ottengo immediatamente una risposta. Se è necessario prima un passaggio intermedio, per generare un file o qualcosa del genere, questo vantaggio è sparito. La seconda cosa è l'aspetto POL (Problem Oriented Language) : la lingua deve essere espandibile senza soluzione di continuità . Quindi, se un linguaggio FORTH simile non è in grado di compilare nuove parole, è inutile.