JavaScript è stato interpretato dal design?

So am I to take it that the interpreted part is a requirement in the language specification, or is it misleading to say that the language is an interpreted programming language when respecting the difference between a language and its many implementations?

I fanatici del linguaggio EcmaScript usano spesso il termine "interprete ES" per riferirsi a un'implementazione di EcmaScript, ma la specifica non usa quel termine. La panoramica della lingua in particolare descrive la lingua in termini indipendenti dall'interprete:

ECMAScript is object-based: basic language and host facilities are provided by objects, and an ECMAScript program is a cluster of communicating objects.

Quindi EcmaScript presuppone un "ambiente host" che è definito come un fornitore di definizioni di oggetti che includono tutti quelli che consentono l'I / O o altri collegamenti al mondo esterno, ma non richiede un interprete.

La semantica delle affermazioni ed espressioni nella lingua è definita in termini di specifiche di completamento che sono banalmente implementate in un interprete, ma le specifiche non lo richiedono.

8.9 The Completion Specification Type

The Completion type is used to explain the behaviour of statements (break, continue, return and throw) that perform nonlocal transfers of control. Values of the Completion type are triples of the form (type, value, target), where type is one of normal, break, continue, return, or throw, value is any ECMAScript language value or empty, and target is any ECMAScript identifier or empty.

The term “abrupt completion” refers to any completion with a type other than normal.

I trasferimenti di controllo non locali possono essere convertiti in array di istruzioni con salti che consentono la compilazione di codice nativo o byte.

"EcmaScript Engine" potrebbe essere un modo migliore per esprimere la stessa idea.

There are no static compilers for JavaScript apparently

Questo non è vero. L'interprete V8 compila internamente il codice nativo, Rhino compila facoltativamente in bytecode Java internamente, e vari interpreti Mozilla ({Trace, Spider, Jager} Monkey usano un compilatore JIT.

V8 :

V8 increases performance by compiling JavaScript to native machine code before executing it, versus executing bytecode or interpreting it.

Rhino :

public final void setOptimizationLevel(int optimizationLevel)

Set the current optimization level. The optimization level is expected to be an integer between -1 and 9. Any negative values will be interpreted as -1, and any values greater than 9 will be interpreted as 9. An optimization level of -1 indicates that interpretive mode will always be used. Levels 0 through 9 indicate that class files may be generated. Higher optimization levels trade off compile time performance for runtime performance. The optimizer level can't be set greater than -1 if the optimizer package doesn't exist at run time.

TraceMonkey :

TraceMonkey adds native‐code compilation to Mozilla’s JavaScript® engine (known as “SpiderMonkey”). It is based on a technique developed at UC Irvine called “trace trees”, and building on code and ideas shared with the Tamarin Tracing project. The net result is a massive speed increase both in the browser chrome and Web‐page content.

La VM V8 JavaScript utilizzata in Chrome non include un interprete. Invece è composto da due compilatori e compila il codice al volo. Uno dei compilatori viene eseguito rapidamente ma genera codice inefficiente, l'altro è un compilatore di ottimizzazione.

Posso capire perché alcune persone considererebbero questo "imbroglio", poiché V8 prende il codice sorgente come input ogni volta che il codice viene eseguito e l'utente deve installare V8. Ma considera un compilatore che emette un eseguibile che include un interprete completo e un bytecode. Allora avresti un programma stand-alone. Non sarebbe molto efficiente.

L'emergere di compilatori JIT per i linguaggi di script ha offuscato la linea di demarcazione tra la compilazione e l'interpretazione fino a un punto in cui la domanda non significa molto. È solo l'interpretazione quando il motore legge una riga di codice e la esegue immediatamente? (Gli script di shell sono ancora in genere implementati in questo modo.) È un'interpretazione quando il motore prende l'intero file, lo compila immediatamente in un codice byte e quindi interpreta il codice byte? (Il motore Mozilla di primo livello funziona in questo modo, come fa CPython.) È un'interpretazione quando il motore analizza una funzione alla volta e JIT lo compila nel codice nativo? Che dire di quei motori che compilano l'intero file in byte code, quindi JIT una funzione alla volta se necessario? (Al giorno d'oggi la maggior parte dei motori di script funziona in questo modo, e la Java VM principale funziona in questo modo eccetto che la compilazione su codice byte avviene prima del tempo.)

Ci sono molte sfumature tra la compilazione e l'interpretazione.

Penso che la definizione più utile per l'interpretazione sia "viene alimentato il codice sorgente del programma al momento dell'esecuzione, senza un passo in avanti separato". Con questa definizione, tutti i motori JavaScript sono interpreti. Ma questa non è certamente l'unica definizione possibile di interpretazione.

Ma JavaScript è progettato per l'interpretazione? In un certo senso, sì: ha una funzione eval così come il costruttore Function che puoi dare al codice del programma come una stringa che verrà eseguita. La capacità di costruire dinamicamente il codice del programma in fase di esecuzione richiede che il motore sia in grado di interpretare il codice sorgente. Ma questo non significa che non puoi fare tutto il resto in anticipo. Anche in un linguaggio compilato come C ++ e C # puoi prendere il codice sorgente, compilarlo in memoria al nuovo codice macchina e quindi eseguirlo. Esistono anche librerie per questo: LLVM + Clang in C ++ e il progetto Roslyn in C #.

Inoltre, il meccanismo di consegna per JavaScript è il codice sorgente; non esiste un codice byte code riconosciuto. C # e Java hanno il loro codice byte ufficiale e tutti si aspettano che C ++ sia consegnato come codice macchina. Ma questo non è ancora un aspetto intrinseco se il linguaggio, solo uno scenario di utilizzo dominante. In effetti, il fumetto ActionScript relativo di JavaScript in Flash viene infatti distribuito come codice byte (il compilatore Flash precompila tutti gli script).

Non esiste una definizione totalmente concordata di "interpretato" o "compilato". Nella classica distinzione, i linguaggi compilati producono un eseguibile binario autonomo, mentre le lingue interpretate richiedono un runtime distribuito per eseguire il codice. Macchine virtuali, bytecode e così via offusca la distinzione.

Ma ecco una possibile definizione utile: una lingua interpretata è una lingua in cui il runtime della lingua standard è in grado di prendere il testo del codice sorgente come input ed eseguirlo. Con questa definizione vengono interpretati Perl, Python, Ruby, JavaScript e script di shell e simili (anche se usano passaggi intermedi come bytecode o anche codice nativo). Java, C #, C ecc. Non lo sono. E JavaScript è interpretato per definizione, anche se la specifica non usa la parola esatta.