2012-01-27 17 views
6

¿Hay algún lenguaje de programación extensible interpretado escrito en C o C++ estándar, independiente de la plataforma?Intérpretes escritos en C o C++ estándar

Me gustaría ser capaz de simplemente poner todas las fuentes en un directorio, compilar las fuentes con cualquier compilador estándar C o C++ y producir un ejecutable que lea e interprete los archivos de script en el lenguaje de scripting designado.

Parece que muchos lenguajes de programación "escrito en C" a menudo incorporan muchas características que dependen de la plataforma que se encuentran, y como resultado, requieren algún programa de configuración Para ejecutar basado en el sistema de destino (por ejemplo, Autoconf), que complica las cosas y limita la compatibilidad multiplataforma.

Motivo de la pregunta:

Tengo interés en aprender sobre el diseño de lenguajes de programación. He jugado con algunos lenguajes de programación de juguetes después de seguir los tutoriales que incluyen yacc, lex y llvm. Sin embargo, recientemente me interesé en estudiar un lenguaje de programación escrito en C/C++ portátil, de esa manera, puedo estudiar el programa y el código en cualquier máquina que admita un compilador C o C++ estándar (posiblemente incluso en mi ipad) y aún así tener una experiencia razonablemente uniforme.

Como esto es sólo para fines educativos, el lenguaje de scripting no necesita soportar características de bajo nivel como C, ni tiene que tener una GUI como Java (no creo que pueda escribir ningún tipo de GUI limitado a C/C++ estándar de todos modos) o cualquier io complicado para ese asunto. Sin embargo, me gustaría que el lenguaje sea lo suficientemente completo como para que sea práctico escribir algunos programas útiles en el idioma (por ejemplo, debería ser posible extender el idioma usando C/C++ para que pueda usarlo como un shell en tty) .

Gracias.

Editar:

@ AndréCaron yo preferiría que si al menos el núcleo de la lengua fue la plataforma 100% independiente. Sería correcto si el lenguaje incluyera una gran biblioteca estándar que dependiera de otras bibliotecas para hacerlo "más útil", sin embargo, me gustaría poder quitar la biblioteca estándar y usar solo el núcleo del lenguaje (posiblemente con una función personalizada). bibliotecas escritas a mano) si quisiera.

+0

Esta es realmente una mejor pregunta para el sitio [programadores] (http://programmers.stackexchange.com). –

+2

¿Cómo es este tema fuera de tema? Parece encajar sólidamente en [temas excluidos de Programmers.SE] (http://programmers.stackexchange.com/faq). –

+0

"Incrustar las fuentes de la biblioteca en mi árbol fuente" no es realmente una forma común de incluir bibliotecas en su proyecto fuera de la plataforma iOS. Si tiene la intención de utilizar C, debería considerar agregar "usar bibliotecas de terceros" y "tratar con autotools" para sus objetivos educativos. – millimoose

Respuesta

9

Tal vez embedded Lua?

Actualmente core Lua sí mismo es probablemente mejor. A primera vista, pensé que la afirmación de eLua de correr en muchos sistemas diferentes significaba que era muy portátil, pero de hecho toma el núcleo de Lua y agrega un montón de controladores de hardware, que obviamente no son tan portátiles.

Ocaml sería otra excelente opción. Reclama "The bytecoded system currently runs on any POSIX-compliant operating system with an ANSI-compliant C compiler" y Caml Light es especialmente adecuado para el aprendizaje. "El sistema de tiempo de ejecución y el intérprete de códigos de bytes están escritos en el estándar C, por lo que Caml Light es fácil de portar a casi cualquier plataforma de 32 o 64 bits".

+0

Tristemente, no. De http://www.eluaproject.net/doc/master/en_building.html: "** eLua ** tiene un sistema de compilación muy flexible [...]. Para usarlo, debe editar un solo archivo de configuración (* platform_conf.h *) ubicado en el directorio específico de la plataforma (* src/platform/ /platform_conf.h*). " – ruakh

+4

Bueno, no es perfecto, pero no creo que exista algo independiente de la plataforma multiplataforma. Si hubiera, entonces todas las plataformas serían consistentes y no habría problemas de plataforma cruzada en absoluto, ¿verdad? Todo sería solo plataforma independiente. El valor de Lua es que los cambios necesarios son pequeños y en un solo archivo, ya han hecho el trabajo para hacer que la plataforma _code_ sea independiente. Tengo entendido que solo estás modificando la construcción, no el intérprete. – Matt

+0

@Matt: Creo que el punto es que las bibliotecas de tiempo de ejecución C (y C++) deben abstraer (casi) todas las diferencias de plataforma. Pero las API estándar de C aún requieren que la aplicación utilice datos específicos de la plataforma, como nombres de archivos. –

6

Lua es realmente su mejor opción. El intérprete central de Lua es lo más minimalista que se puede obtener. La distribución incluye un archivo MAKE, pero es lo más escueto posible. Incluso hay instrucciones que explican qué archivos necesita para compilar solo el lenguaje central, cuáles son la biblioteca estándar de Lua y cuáles son los intérpretes de línea de comandos.

El lenguaje principal en sí no toca ninguna API o encabezados específicos de la plataforma.La biblioteca estándar sí lo hace, pero solo de la manera más mínima. Y no tiene tiene para construir la biblioteca estándar si no tiene ganas.

Hay algunas # definiciones que puede utilizar para configurar la compilación, pero eso es principalmente para cosas como la construcción de DLL y similares.

Nota: El propósito de las herramientas automáticas y otras utilidades de configuración de compilación específicas de la plataforma es permitir que las bibliotecas envuelvan efectivamente las cosas específicas de la plataforma dentro de una interfaz neutral de plataforma. No hay mucho que pueda hacer en la mayoría de las plataformas con librerías de C o C++ de plataforma pura neutral. Ni siquiera puede acceder a árboles de directorios y buscar archivos, y mucho menos cosas realmente útiles como abrir una ventana. Para aplicaciones stdin/stdout simples, eso podría ser suficiente. Pero para la gran mayoría de los casos, no lo es.

Lo que sugiero es que te acostumbres a tener que configurar una compilación para una plataforma específica. A menos que su dominio sea de aplicaciones científicas (y en algunos casos, ni siquiera entonces), no obtendrá mucho de la programación independiente de la plataforma. Tendrá que aprender a trabajar con este tipo de bibliotecas.

Lua es valor atípico cuando se trata de bibliotecas. La mayoría de las bibliotecas no son listas de archivos que puede meter en un directorio y compilar de cualquier manera. Cuanto antes descubra cómo trabajar con las herramientas que utilizan las bibliotecas, mejor le irá.

0

LUA y TCL son los dos idiomas interpretados más simples, así que obtenga una copia del código fuente para ambos y examínelo. Sin embargo, creo que su pregunta está más relacionada con la vinculación estática frente a la vinculación compartida. Un programa enlazado estáticamente no tiene dependencias del sistema más allá de la interfaz del núcleo, pero un programa vinculado dinámicamente requiere que se instale el conjunto correcto de bibliotecas compartidas.

Con un lenguaje como Python, debe preocuparse por las propias bibliotecas de Python (llamados módulos), así como también por las bibliotecas binarias compartidas de las que depende un módulo. Python en sí mismo generalmente se crea utilizando bibliotecas compartidas, pero it can be built statically. Además, he creado un código binario de Python that uses the Linux shared library RUNPATH feature so that all binary dependencies can be bundled with Python en su propia jerarquía de carpetas.

Si su pregunta es más acerca de la vinculación, eche un vistazo a cómo se construye StaticPython en comparación con las secuencias de comandos de construcción de Python dinámicas estándar y Pybuild usando RUNPATH.

0

Casi todos los lenguajes de script recientes están escritos en C o C++: Perl, bash, csh, PHP, HTML, JavaScript, marca, vim, TCL, etc., etc.

El hecho de que la construcción de ellos requiere una configuración no es una característica del intérprete tanto como una adaptación para construir en múltiples plataformas — generalmente considerado algo bueno.

Todos son extensibles en el sentido de que puede escribir funciones que crean nuevas funcionalidades.