Qual è la definizione di settore di un interprete (al contrario di un compilatore)?

This definition would clearly put the usual execution of Java bytecode in the domain of interpretation, no matter how much JIT compilation is done. I have encountered opinions in discussions on this site that clearly and vehemently state the opposite, i.e. that Java Bytecode execution thingies are compilers.

Bene, le due definizioni non si escludono a vicenda. Un interprete può contenere un compilatore (in effetti, la maggior parte degli interpreti moderni contiene almeno un compilatore bytecode).

Ma penso che la definizione intuitiva che la maggior parte delle persone usa sia qualcosa del tipo:

• un compilatore crea un codice nativo che viene quindi eseguito direttamente dalla CPU
• un interprete ha una sorta di "interpreter main loop" che legge le istruzioni (o dichiarazioni di codice sorgente o qualcosa di simile a codice P precompilato o bytecode) ed esegue le istruzioni di conseguenza.

Con questa distinzione, un "interprete" è di solito un ordine di grandezza più lento di un programma "compilato". Quindi, quando parliamo di prestazioni, questa definizione è più utile della classica definizione CS.

Da Pragmatica del linguaggio di programmazione di Michael Scott, terza edizione .

La spiegazione di alto livello della compilazione è:

The compiler translates the high-level source program into an equivalent target program (typically in machine language), and then goes away. At some arbitrary later time, the user tells the operating system to run the target program. The compiler is the locus of control during compilation; the target program is the locus of control during its own execution.

Una spiegazione di alto livello per l'interpretazione è:

Unlike a compiler, an interpreter stays around the the execution of the application. In fact, the interpreter is the locus of control during that execution. In effect, the interpreter implements a virtual machine whose "machine language" is the high-level programming language. The interpreter reads statements in that language more or less one at a time, executing them as it goes along.

Tuttavia, alcune implementazioni linguistiche mescolano anche la compilazione e l'interpretazione, quindi le linee diventano leggermente più sfocate. In tal caso, il programma sorgente viene tradotto in un programma intermedio che viene eseguito da una macchina virtuale. Il codice sorgente è compilato e l'output della compilation è interpretato.

La compilazione avviene quando un traduttore analizza a fondo i file di origine di input e crea un output che non assomiglia alla fonte originale. Ciò significa che la compilazione richiede, secondo Scott, "analisi e trasformazioni non banali".

Is the above definition of interpreters false from the viewpoint of industry people in general?

No

Or is it just false for Java people?

No

Is the view of Java as a fully compiled language an alternate, but minority view?

No

Or just a few loonies?

No

L'ambiente di esecuzione Java è più complicato di quanto previsto da quelle definizioni CS teoriche. Ma sia i teorici che gli sviluppatori pratici sono d'accordo con questo.

Le definizioni teoriche come queste sono progettate per uno scopo particolare; cioè un ragionamento formale su come i programmi sono "compilati" e "eseguiti". Se è necessario modellare Java in questo modo e includere la compilazione JIT nella modellazione, esistono modi per gestirlo. Ad esempio potresti fare "call native compiled method" come un'operazione primitiva dell'interprete.

La realtà è che la piattaforma di esecuzione Java utilizza sia la compilazione che l'interpretazione sia in senso intuitivo che teorico. Quindi, se hai bisogno di modellare la piattaforma Java a quel livello di dettaglio, devi incorporarlo nella modellazione.

Generalmente considero qualsiasi programma che analizza e converte codice in un livello inferiore da un compilatore. Quindi considererei definitivamente Java un compilatore. Come sarebbero compilatori C #, Python, PHP, ecc, in quanto tutti riducono il codice sorgente in bytecode, che viene poi eseguito. C ++, Delphi e alcuni altri che compilano direttamente per codice eseguito in modo nativo chiamerei (e vedo molti chiamano) "compilatori di codice nativo".

Un interprete, almeno nel modo in cui l'ho imparato indietro quando , è un programma che analizza le righe di uno script uno alla volta e li esegue direttamente. Cioè, non esiste un codice di livello intermedio o inferiore. Non sono a conoscenza di linguaggi 'moderni' che sono interpreti.

Per quanto riguarda la tua definizione di "compilatore", non penso che implichi necessariamente che il codice Java non sia compilato. Devi solo interpretare 'lingua O' come set di istruzioni bytecode.

Dal punto di vista pratico puoi pensare che qualcosa venga interpretato non appena puoi fare questo pseudo codice:

a = 6
b = 7
eval("c = a + b")
print c

Non discuterò di problemi di sicurezza, best practice quando usare e quando non usare eval e così via.

JVM e .NET consentono (con alcune chiamate a funzioni di libreria standard, wrapper e altri problemi) di compilare il codice al volo:

a = 6
b = 7
assembly = my_implementation_of_eval("function sum(x,y) { return x + y} ")
print assembly.call("sum",a,b);

Ma quello è solo un compilatore con la capacità di caricare dinamicamente un modulo. Confronta l'integrazione profonda con le vars locali e creando nuove variabili nell'interprete.

Un compilatore di solito traduce qualcosa dalla lingua A alla lingua B. Il linguaggio B può essere codice macchina (per una CPU esistente o virtuale), ma ci sono compilatori che emettono codice sorgente in una lingua diversa.

Un interprete normalmente esegue un programma scritto nella lingua X.