¿JavaScript se interpreta por diseño?

Pregunta:

Soy cauteloso al hacer esta pregunta porque puede parecer demasiado fastidiosa. Acabo de abrir JavaScript: The Definitive Guide, y dice que en la primera página del capítulo 1

"JavaScript es un lenguaje de programación interpretado de alto nivel, dinámico y sin tipo"

Entonces, ¿debo considerar que la parte interpretada es un requisito en la especificación del lenguaje, o es engañoso decir que el lenguaje es un lenguaje de programación interpretado cuando se respeta la diferencia entre un lenguaje y sus muchas implementaciones?

Aparentemente, no hay compiladores estáticos para JavaScript: https://stackoverflow.com/questions/1118138/is-there-a-native-machine-code-compiler-for-javascript, por lo que tal vez sea solo un reflejo de esto.

Respuesta:

Entonces, ¿debo considerar que la parte interpretada es un requisito en la especificación del lenguaje, o es engañoso decir que el lenguaje es un lenguaje de programación interpretado cuando se respeta la diferencia entre un lenguaje y sus muchas implementaciones?

Los fanáticos del lenguaje EcmaScript a menudo usan el término "intérprete ES" para referirse a una implementación de EcmaScript, pero la especificación no usa ese término. La descripción general del idioma en particular describe el idioma en términos independientes del intérprete:

ECMAScript se basa en objetos: los objetos proporcionan el lenguaje básico y las facilidades de host, y un programa ECMAScript es un grupo de objetos que se comunican.

Por lo tanto, EcmaScript asume un "entorno de host" que se define como un proveedor de definiciones de objetos, incluidos todos aquellos que permiten E / S o cualquier otro enlace al mundo exterior, pero no requiere un intérprete.

La semántica de las declaraciones y expresiones en el lenguaje se define en términos de especificación de finalización que se implementan trivialmente en un intérprete, pero la especificación no lo requiere.

8.9 El tipo de especificación de finalización

El tipo Completion se usa para explicar el comportamiento de las declaraciones ( break , continue , return y throw ) que realizan transferencias de control no locales. Los valores del tipo de finalización son triples de la forma ( tipo , valor , objetivo ), donde el tipo es uno de normal , romper , continuar , devolver o lanzar , el valor es cualquier valor del lenguaje de ECMAScript o vacío , y el objetivo es cualquier identificador de ECMAScript o vacio .

El término "finalización abrupta" se refiere a cualquier finalización con un tipo diferente al normal .

Las transferencias de control no locales se pueden convertir en matrices de instrucciones con saltos que permiten la compilación nativa o de código de bytes.

"EcmaScript Engine" podría ser una mejor manera de expresar la misma idea.


Aparentemente, no hay compiladores estáticos para JavaScript.

Esto no es verdad. El "intérprete" V8 compila internamente en código nativo, Rhino opcionalmente compila internamente en código de bytes Java y varios intérpretes de Mozilla ({Trace, Spider, Jager} Monkey) usan un compilador JIT.

V8 :

V8 aumenta el rendimiento compilando JavaScript en código de máquina nativo antes de ejecutarlo, en lugar de ejecutar bytecode o interpretarlo.

Rinoceronte :

public final void setOptimizationLevel(int optimizationLevel)

Establece el nivel de optimización actual. Se espera que el nivel de optimización sea un número entero entre -1 y 9. Cualquier valor negativo se interpretará como -1, y cualquier valor mayor que 9 se interpretará como 9. Un nivel de optimización de -1 indica que el modo interpretativo siempre será usado. Los niveles del 0 al 9 indican que se pueden generar archivos de clase. Los niveles de optimización más altos compensan el rendimiento en tiempo de compilación por el rendimiento en tiempo de ejecución. El nivel del optimizador no se puede establecer en un valor superior a -1 si el paquete optimizador no existe en tiempo de ejecución.

TraceMonkey :

TraceMonkey agrega compilación de código nativo al motor JavaScript® de Mozilla (conocido como “SpiderMonkey”). Se basa en una técnica desarrollada en UC Irvine llamada "árboles de rastreo", y se basa en el código y las ideas compartidas con el proyecto Tamarin Tracing. El resultado neto es un aumento masivo de la velocidad tanto en el cromo del navegador como en el contenido de la página web.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

web tasarım