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

Question

Si hay diseñadores de lenguajes (o personas que simplemente lo saben), 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 está escrito el intérprete?

Lo que me hizo pensar en esto fue la pregunta SO sobre una función similar a stripslashes() en Python.Mi primer pensamiento fue "¿por qué no definir el tuyo propio y llamarlo cuando lo necesites?", pero surgió la pregunta:¿Es preferible, para tal 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 lenguajes "interpretados" y "compilados" es muy confusa hoy en día.Por ejemplo, lo primero que hace Python cuando ve el código fuente es compilarlo en una representación de código de bytes, esencialmente lo mismo que hace Java al compilar archivos de clase.Esto es lo que contienen los archivos *.pyc.Luego, el tiempo de ejecución de Python ejecuta el código de bytes sin consultar la fuente original.Tradicionalmente, un lenguaje puramente interpretado haría referencia al código fuente continuamente al ejecutar el programa.

Al crear un lenguaje, es un buen enfoque construir una base sólida sobre la cual se puedan implementar las funciones de nivel superior.Si tiene un sistema de manejo de cadenas rápido y sólido, entonces el diseñador del lenguaje puede (y debe) implementar algo como stripslashes() fuera del tiempo de ejecución base.Esto se hace al menos por algunas razones:

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

El hecho de que un lenguaje como Python se compila en código de bytes y se ejecuta 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, similar a lo que ya hacen Java y .NET, para aumentar aún más el rendimiento.De hecho, IronPython compila Python directamente en código de bytes .NET, que luego se ejecuta utilizando el sistema .NET, incluido 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.Esta es la razón por la que módulos como el analizador de expresiones regulares están escritos en C en lugar de 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 ningún beneficio en usar la biblioteca C correspondiente.

Answer 2

También hay una tendencia creciente a reimplementar lenguajes que tradicionalmente se consideran "interpretados" en una plataforma como JVM o CLR, y luego permitir 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 y 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

Consulte la sección 'Artículos' en www.lua.org.

Especialmente La implementación de Lua 5.0

Lua define todas las funciones estándar en el código subyacente (ANSI C).Creo que esto se debe principalmente a razones de rendimiento.Recientemente, es decirlas funciones 'string.*' obtuvieron una implementación alternativa en Lua puro, lo que puede resultar vital para subproyectos donde Lua se ejecuta sobre .NET o Java (donde no se puede usar código C).

Answer 4

Siempre que esté utilizando una API portátil para el código base compilado como el Biblioteca estándar ANSI C o STL en C++, aprovechar esas funciones le impediría reinventar la rueda y probablemente proporcionaría un intérprete más pequeño y más rápido. lua adopta este enfoque y definitivamente es pequeño y rápido en comparación con muchos otros.