"No existe el" lenguaje compilado "o el" lenguaje interpretado ". Si el implementador del lenguaje elige escribir un compilador, un intérprete o un intérprete. cualquier cosa intermedia es un detalle de implementación y no tiene nada que ver con el idioma. "No existe el "lenguaje compilado" o el "lenguaje interpretado"
¿La afirmación anterior es verdadera?
Sí, es cierto en la interpretación más estricta. Puede encontrar tanto un C++ interpreter como un Javascript compiler, por ejemplo. Sin embargo, encontrará que algunos tipos de idiomas (tipicamente tipados, por ejemplo) se prestan bien a la compilación de código nativo. Otros lenguajes (tipificados dinámicamente, por ejemplo) se implementan comúnmente utilizando la compilación de códigos de bytes combinada con un entorno de ejecución de máquinas virtuales.
Tipo de. Generalmente, tanto los intérpretes como los compiladores primero necesitan analizar el código fuente y convertirlo en una representación, llamada AST (árbol de sintaxis abstracta). Un compilador luego convierte el AST en código ejecutable (a través de varias transformaciones), mientras que un intérprete puede simplemente 'interpretar' directamente el AST o, a veces, compilarlo y ejecutarlo (compilación justo a tiempo).
La afirmación es correcta porque no tiene nada que ver con el idioma: en teoría, puede escribir un intérprete y compilador para cualquier idioma. Cuál usar realmente depende del caso de uso, el escenario y el entorno.
Un compilador tiene la ventaja de que solo necesita hacer su trabajo una vez, independientemente de la frecuencia con la que ejecute el programa. Un intérprete necesita analizar el origen cada vez (o hacer un poco de almacenamiento en caché), por lo tanto, tiene una sobrecarga para cada ejecución que puede llevar más tiempo que el tiempo de ejecución real del programa final. Por otro lado, un intérprete es más flexible (puede tomar en cuenta el entorno actual y, por lo tanto, realizar optimizaciones que un compilador no puede hacer). Pero las diferencias no se detienen aquí, estos son solo dos puntos obvios.
He escrito varios intérpretes y compiladores, ninguno de ellos construido o utilizado un AST. –
¿Qué usaste en su lugar? ¿Y cómo hiciste el análisis semántico? – DarkDust
La afirmación anterior es verdadera.
Por otra parte, uno podría argumentar que no es lo suficientemente cierto en el mundo real. Si todas las implementaciones existentes de un idioma se basan en la compilación, el lenguaje puede denominarse legítimamente como un lenguaje compilado.
El diseño del idioma tiene que ver con la gramática para la parte de entrada de nivel superior y el código de salida de nivel inferior que se ejecuta en el destino.
Hay un árbol de sintaxis abstracta entre los dos.
Tradicionalmente, si escribe el código de salida de nivel inferior para ejecutar en una plataforma de hardware particular y su conjunto de instrucciones específico, la salida se "compila".
Si alguien decide escribir un intérprete para actuar como el objetivo, el código de salida es el conjunto de instrucciones o el código de bytes que espera el intérprete. El nivel adicional de direccionamiento indirecto significa que el código interpretado se puede ejecutar en cualquier plataforma de hardware que tenga una implementación de intérprete.
Por lo tanto, la afirmación es correcta si llamamos "lenguaje de diseño" la gramática y la pieza lexer/analizador.
No es estrictamente correcto si estamos hablando del generador de código.
Es posible emitir un idioma en particular interpretado y compilado simplemente llamando a diferentes generadores de código para recorrer el AST.
Así que tal vez así es como la distinción es borrosa. Pero creo que todavía está allí.
Creo que estás malinterpretando la pregunta. Nadie niega la existencia de compiladores e intérpretes. Lo que se niega es la existencia de lenguajes compilados e idiomas interpretados. Un lenguaje es solo un conjunto de reglas matemáticas abstractas. Un idioma no está compilado o interpretado. Un idioma solo * es *. Como evidencia, solo tome uno de los miles de millones de lenguajes de programación para los que * existe * implementación. (Decir, Smalltalk-71 o Modula-1.) –
Estoy diciendo más o menos lo que dicen los demás. ¿Cómo es que soy señalado como el que está malentendiendo? Estoy hablando de los detalles de implementación subyacentes, pero estoy llegando a la misma conclusión que la mayoría de los otros encuestados. – duffymo
Es cierto solo en el sentido de que, en última instancia, tanto los lenguajes compilados como los interpretados deben generar código máquina. Tiene un efecto en el lenguaje en la medida en que tradicionalmente ciertos paradigmas son más fáciles en uno sobre el otro. Por ejemplo, en general, los cierres o los bloques son más fáciles de implementar en idiomas interpuestos que en los compilados. Esto es cierto ya que efectivamente no existe diferencia entre el tiempo de compilación y el alcance del tiempo de ejecución en los lenguajes interpretados. Por lo tanto, el alcance dinámico TENDS es más fácil de implementar en los idiomas interpretados.
Los lenguajes puramente interpretados nunca generan códigos de máquina. Por el contrario, cada enunciado se procesará utilizando el equivalente de un árbol if-ifelse-else o una sentencia switch-case. El intérprete no genera ningún código de máquina de las declaraciones que examina; más bien, simplemente hace las acciones apropiadas directamente. – supercat
Una implementación determinada de un idioma será un compilador "puro" (cuyo resultado es ejecutado por un procesador como código), un intérprete "puro" (cada enunciado se examina por primera vez, en formato de fuente sin formato) , mientras se ejecuta, y nada sobre la interpretación se almacena en caché), o un híbrido entre los dos. Es bastante fácil distinguir los casos "puros" de los híbridos, pero algunos híbridos están "más cerca" de compilarse que otros; las líneas entre un híbrido "compilado" y uno "interpretado" pueden ser bastante borrosas.
No creo que ningún lenguaje tenga un uso sustancial, aparte del lenguaje ensamblador (para el cual el término "ensamblador" se usa generalmente en lugar de "compilador"), que no podría implementarse al menos prácticamente en una intérprete híbrido (el rendimiento de un intérprete "puro" tiende a ser horrible con cualquiera de las construcciones de bucle menos triviales). Sin embargo, existen algunos lenguajes que permiten la generación dinámica de código de formas que no serían susceptibles de compilación.
Por cierto, cuando digo "fuente sin formato", no siempre me refiero al formato de texto. Mi primera calculadora programable tenía 99 pasos de programa, cada uno de los cuales se podía configurar con una pulsación de tecla o una de las pocas instrucciones de secuencia especiales. El programa nunca existiría en una forma de texto legible por el hombre per se, sino más bien como una secuencia de números clave. Sin embargo, describiría eso como un "lenguaje" puramente interpretado ya que cada paso del programa se evaluó de manera completamente independiente.
Todo el compilador/intérprete depende de cuáles sean sus intenciones para su programa. Un programa compilado es uno que se convierte en código de máquina. Un intérprete se usa para leer un idioma intermedio y ejecutarlo en la máquina. Por ejemplo, cuando compila Java, se convierte en el Bytecode de Java y el intérprete lo lee y ejecuta (lo que también explica la desventaja de velocidad en comparación con C++).
Realmente no creo que su afirmación al respecto no tenga nada que ver con el idioma es totalmente cierto. Una de las cosas principales acerca de Java es que se supone que se puede ejecutar en diferentes arquitecturas. Si fuera compilado eso no sería posible.
"Un programa compilado es uno que se convierte en código de máquina". Los compiladores no siempre se enfocan en el código de máquina. Por ejemplo, los compiladores C# y OCaml generan bytecodes para máquinas virtuales. –
Vale la pena señalar que, para (algunos) idiomas que incluyen una instrucción de tipo "eval" (especialmente si no es posible determinar hasta el tiempo de ejecución si un bloque determinado es código o datos), incluso la versión más puramente compilada de el programa dado debe ser parcialmente interpretado. Para dichos idiomas, no es posible compilarlos por completo (el código compilado debe contener un intérprete para el idioma).
Como ejemplo, consideremos el siguiente código:
set s [eval {sum $a $b $c}]
Para el anterior código Tcl, no es posible determinar hasta que el tiempo de ejecución si el bloque (dentro de la {}) es el código o no.
-1 "debe interpretarse parcialmente". Aún no tienes que interpretar. –
¿Cómo, exactamente, podrías compilar un bloque como el anterior cuando no puedes estar seguro si partes de él son datos o código? O, mejor aún, codifique como [$ something {sum $ b $ c}] ... que no sabe si el valor de la variable $ something es [eval] o [puts] (es decir, el valor en el rizado llaves pueden ser código o datos) hasta el tiempo de ejecución. – RHSeeger
De la misma manera, SBCL compila '(EVAL '(+ 2 3))' o cualquier otro lenguaje compilado que sea compatible con la metaprogramación. Code is data no impide la compilación. –
¿Es esta tarea? – bcat
¿Esta pregunta parece una tarea? – Tony
¿De dónde estás citando? –