programar - jdoodle compiler c#
Meta-programación: escriba en un idioma X, compile en múltiples idiomas como C#, PHP, Java, C (5)
En todos los proyectos que he realizado a lo largo de los años, nunca encontré un requisito como este, aunque parece tan sencillo en papel: escriba un complemento para muchos CMS conocidos.
Obviamente, cada sistema de complementos (o sistema de extensión) es diferente y esto requiere un código de puente específico a través de un patrón de adaptador. Pero el núcleo debe escribirse una vez. No espero que los usuarios de WordPress utilicen un puente PHP-Java, y no espero que los usuarios de DotNetNuke utilicen un puente .NET-Native (aunque es más fácil de concebir).
A mi modo de ver, el núcleo debe ser compilable en tres dominios principales que cubren la mayoría de los sistemas CMS:
- nativo, el idioma intermedio podría ser C, o C ++. Target puede ser usado como extensión PHP.
- MSIL / CIL para lenguajes basados en .NET
- Código de bytes de Java para sistemas basados en Java
C # y Java se traducen bastante bien entre sí, pero C y C # son mucho más difíciles. En última instancia, sería bueno agregar otros objetivos, para no forzar a un usuario de WordPress o WikiMedia a instalar una extensión antes de usar un complemento.
Estoy seguro de que esto ha surgido con otros también. ¿Cuál es una forma común de abordar tales problemas? ¿Debo definir un DSL primero y usar DMS o similar para transformar? ¿Otras opciones?
Como no hay un solo idioma que compile directamente a todos sus objetivos, no pase por alto el denominador común más bajo. Puede crear su complemento usando C y luego ajustar el resultado para cada plataforma (PInvoke, JNI, extensión PHP). Si no te gusta la idea de escribir un complemento complejo en C, considera hacer el trabajo pesado utilizando un lenguaje de script pequeño, fácil de usar e integrable. Lua parece razonable. Su resultado final sería un esqueleto de C que simplemente delega solicitudes y respuestas desde y hacia el host y los scripts.
La transformación del programa está relacionada, aunque el esfuerzo por construir una transformación efectiva es significativo. En teoría, podría transformar de la fuente a la fuente y utilizar el compilador específico de la plataforma. Eche un vistazo a TXL y Stratego / XT para tener una idea de lo que está involucrado.
Solo estaba en un proyecto que usaba un meta-lenguaje que compilaba tanto en Java como en C. Utilizaba una sintaxis similar a Java y simulaba la funcionalidad de clase en C (y la parte C dependía mucho de las macros para "Convertir" algunos del código).
Fue horrible. Al recibir esta pila para mantener, simplemente la dividimos en dos bases de código y partimos de allí. Sé que la compañía inicial tenía algunas personas excelentes, pero es algo demasiado difícil de hacer (especialmente porque ambos estaban compilando en plataformas integradas).
Soy el responsable de DMS , que es a lo que creo que te refieres en tu pregunta.
Al intentar generar código para múltiples dominios de destino, de alguna manera debe expresar cómo asignar la especificación a los objetivos individuales, sin importar qué maquinaria utilice para hacerlo.
Se presentan problemas difíciles cuando la brecha semántica entre el lenguaje de especificación es diferente para cada uno de los objetivos. (Los generadores de código multi-destino más comunes que he encontrado tienden a producir para lenguajes de salida del mismo tipo, lo que evita este problema).
Una forma de hacerlo es escribir un traductor por separado para cada idioma de salida. Eso funciona, a costa de mucho trabajo. Otra forma de hacerlo es traducir el lenguaje de especificación a un idioma / representación / dominio intermedio en el que se han manejado la mayoría de los problemas de traducción (por ejemplo, un lenguaje de procedimiento abstracto), y luego crear traductores del dominio intermedio a los objetivos individuales . Esto suele ser mucho más fácil. Si tiene una variedad real de objetivos, puede encontrar que algunos objetivos tienen algunas cosas en común, pero no con otras; en este caso, lo que desea son múltiples representaciones intermedias, una para cada conjunto de puntos en común.
Todo esto es ortogonol a cómo expresan estos traductores. Puedes escribirlos como compiladores clásicos; Estarás ocupado durante mucho tiempo. Puede escribirlos como algún tipo de traducción dirigida por sintaxis desde una especificación de entrada capturada como un gráfico ("rastrear el gráfico y escupir el texto para cada nodo") que parece bastante común (la mayoría de los generadores de código "basados en modelos" parecen ser de este tipo), pero hacerlo de esta manera no ofrece mucha ayuda, además de la idea de hacerlo de esta manera.
La forma en que me gusta, y la razón por la que construí DMS (y otros construyeron TXL y Stratego), es usar transformations fuente a fuente, porque de esta manera puede escribir la asignación de su idioma de entrada a su idioma de salida como reglas que puede inspeccionar que son esencialmente independientes de la maquinaria de transformación subyacente; Esta es una gran ganancia si va a escribir, en efecto, muchas reglas, lo que ocurre especialmente cuando se dirige a múltiples idiomas. Los motores de transformación tienen otra gran ventaja sobre los generadores de código que solo escupen texto: puede procesar la salida de una etapa del traductor aplicando más transformaciones. Esto significa que puede optimizar el código, puede crear reglas más simples (porque puede usar una cadena de reglas en lugar de un cálculo que representa el producto cruzado, que siempre es grande y peludo), y puede traducir a través de varios niveles de dominios intermedios.
Ahora, la otra razón por la que construí DMS de la manera que lo hice, fuerza la separación clara de cada uno de los "dominios" (especificación de entrada, dominios de salida, dominios intermedios). Usted (y las transformaciones) NUNCA se confunde con respecto a lo que representa una estructura. Stratgo y TXL IMHO hicieron el tonto aquí; solo manipulan la representación "uno" a la vez. Si está traduciendo entre dos notaciones A y B, tiene que configurar un dominio de "unión" (IMHO) que tenga tanto A como B en él. Y tiene que preocuparse de alguna manera, si tiene una parte de sintaxis "+" tanto en A como en B, si "+" significa el "+" en el dominio A, o el "+" en el dominio B. Si no puedes saber, ¿cómo vas a saber qué transformaciones aplicar a ella?
La idea de refinar a través de múltiples dominios y usar transformaciones para hacerlo, por desgracia, no son mías. Fueron propuestos por James Neighbors ( la fuente del término "análisis de dominio") en la década de 1980, para su sistema Draco . Pero me pongo de pie sobre los hombros de gigantes. DMS hereda los conceptos de dominio de los Vecinos y los fundamentos de transformación. Una diferencia es que DMS está diseñado para dominios de escala, arbitrarios (DSL, así como para los lenguajes de programación actuales; tiene módulos de lenguaje predefinidos para C ++, C #, Java, JavaScript, ...), y realiza análisis en profundidad para respaldar las transformaciones.
fantom compila a java y .net clr
No lo he usado, solo lo vi aparecer en una lista de correo el mes pasado.