Idiomas interpretados: aprovechar el lenguaje compilado detrás del intérprete

Question

Si hay diseñadores de idiomas (o personas que simplemente lo conocen), tengo curiosidad acerca de la metodología detrás de la creación de bibliotecas estándar para lenguajes interpretados. Específicamente, ¿cuál parece ser el mejor enfoque? ¿Definir funciones/métodos estándar en el lenguaje interpretado o realizar el procesamiento de esas llamadas en el lenguaje compilado en el que se escribe el intérprete?

Lo que me hizo pensar sobre esto fue la pregunta SO sobre una función similar a stripslashes() en Python. Mi primer pensamiento fue "¿por qué no definir el suyo y simplemente llamarlo cuando lo necesite?", Pero planteó la pregunta: ¿es preferible, para dicha función, dejar que el lenguaje interpretado maneje esa sobrecarga, o sería mejor escribir una extensión y aprovechar el lenguaje compilado detrás del intérprete?

Answer 1

La línea entre los idiomas "interpretados" y "compilados" es realmente difusa en estos días. Por ejemplo, lo primero que hace Python cuando ve el código fuente es compilarlo en una representación de bytecode, esencialmente lo mismo que hace Java al compilar archivos de clase. Esto es lo que contienen los archivos * .pyc. Entonces, el tiempo de ejecución de Python ejecuta el bytecode sin referirse a la fuente original. Tradicionalmente, un lenguaje puramente interpretado se referiría continuamente al código fuente al ejecutar el programa.

Al construir un idioma, es una buena forma de construir una base sólida sobre la que pueda implementar las funciones de nivel superior. Si tiene un sistema de manejo de cadenas sólido y rápido, el diseñador del lenguaje puede (y debe) implementar algo así como stripslashes() fuera del tiempo de ejecución base. Esto se hace por al menos unos pocos motivos:

• El diseñador del idioma puede demostrar que el lenguaje es lo suficientemente flexible para manejar ese tipo de tarea.
• El diseñador de idiomas realmente escribe código real en el idioma, que tiene pruebas y por lo tanto muestra que la base es sólida.
• Otras personas pueden leer, pedir prestado e incluso cambiar la función de nivel superior más fácilmente sin tener que ser capaces de construir o incluso comprender el núcleo del lenguaje.

El hecho de que un lenguaje como Python se compile para escribir y ejecutar código no significa que sea lento. No hay ninguna razón por la que alguien no pueda escribir un compilador Just-In-Time (JIT) para Python, en la misma línea de lo que ya hacen Java y .NET, para aumentar aún más el rendimiento. De hecho, IronPython compila Python directamente a .NET bytecode, que luego se ejecuta utilizando el sistema .NET, incluido el JIT.

Para responder a su pregunta directamente, la única vez que un diseñador de lenguaje implementaría una función en el lenguaje detrás del tiempo de ejecución (por ejemplo, C en el caso de Python) sería maximizar el rendimiento de esa función. Es por eso que los módulos como el analizador de expresiones regulares se escriben en C en lugar de en Python nativo. Por otro lado, un módulo como getopt.py se implementa en Python puro porque todo se puede hacer allí y no hay beneficio en usar la biblioteca C correspondiente.

Answer 2

También hay una tendencia creciente de volver a implementar idiomas que tradicionalmente se consideran "interpretados" en una plataforma como JVM o CLR, y luego permiten un fácil acceso al código "nativo" para la interoperabilidad. Entonces, desde Jython y JRuby, puede acceder fácilmente al código Java, y desde IronPython e IronRuby, puede acceder fácilmente al código .NET.

En casos como estos, la capacidad de "aprovechar el lenguaje compilado detrás del intérprete" podría describirse como el principal motivador para la nueva implementación.

Answer 3

Siempre que utilice una API portátil para la base de código compilado como ANSI C standard library o STL en C++, aprovechar esas funciones evitará reinventar la rueda y probablemente proporcione un intérprete más pequeño y rápido. Lua toma este enfoque y definitivamente es pequeño y rápido en comparación con muchos otros.

Answer 4

Consulte la sección 'Papeles' en www.lua.org.

Especialmente The Implementation of Lua 5.0

Lua define todas las funciones estándar en el (ANSI C) código subyacente. Creo que esto es principalmente por motivos de rendimiento. Recientemente, es decir, las funciones 'string. *' Obtuvieron una implementación alternativa en Lua puro, que puede resultar vital para los subproyectos donde Lua se ejecuta sobre el tiempo de ejecución .NET o Java (donde el código C no se puede usar).