Extender el compilador de Mono C#: ¿hay alguna documentación o precedente?

Question

Actualmente estoy involucrado en una interesante investigación de lenguaje de programación que, hasta ahora, se ha centrado en la ampliación del próximo compilador Java 7.0 con algunas características muy potentes basadas en la productividad del programador. El trabajo debería ser igualmente aplicable a lenguajes de programación relacionados como C#.

Actualmente estoy explorando las opciones para el prototipado de un puerto C# de la funcionalidad. Preferiría opciones de código abierto para que los frutos de este trabajo puedan compartirse con la audiencia más amplia posible. Por lo tanto, el compilador Mono C# parece ser el punto de partida más obvio. Soy un desarrollador experimentado de C# por lo que escribir el código no es el problema. Estoy principalmente preocupado por extender el compilador de una manera sostenible y compatible. En Mono FAQ sobre el tema (link) se afirma que "Mono ya se ha utilizado como base para probar nuevas ideas para el lenguaje C# (hay tres o cuatro compiladores derivados del compilador C# de Mono)". Lamentablemente, no hay más indicadores que este y, hasta el momento, las búsquedas de Google no han cambiado nada.

Me pregunto si alguien tiene alguna información sobre esto. ¿Tiene mcs/gmcs/dmcs tiene un modelo estándar de extensibilidad? Específicamente, realizaré algunas transformaciones interesantes en el árbol de sintaxis abstracta de un programa. ¿Existe un mecanismo estándar para insertar funcionalidad en la cadena del compilador entre la generación del árbol de sintaxis abstracta y el verificador de tipos y luego la generación de código?

Hasta ahora he escrito algunas extensiones ad-hoc para el código (principalmente en el generador de código) pero esta no parece ser una solución mantenible especialmente dado que tengo la intención de mantener mis extensiones actualizadas con el tronco Git de Mono tanto como sea posible. Además, sería bueno poder actualizar mis extensiones sin tener que volver a compilar todo el compilador cada vez que realice un cambio. Me gustaría poder ajustar todas mis manipulaciones AST en un único ensamblado .NET que podría cargarse dinámicamente por mcs/gmcs/dmcs sin tener que hackear el código del compilador central directamente.

Cualquier idea o sugerencia sobre la ampliación del compilador de Mono C# sería gratamente recibida.

Actualizaciones (23 Octubre 2010)

En respuesta a las respuestas a mi pregunta, decidí que iba a empezar a trabajar en una rama de Mono con el fin de crear un modelo de extensibilidad simple para el compilador. Está en sus primeras etapas, pero aquí está en GitHub:

http://github.com/rcook/mono-extensibility

Y el principal compromiso es: http://github.com/rcook/mono-extensibility/commit/a0456c852e48f6822e6bdad7b4d12a357ade0d01

Si alguien estaría interesado en colaborar en este proyecto, por favor hágamelo saber!

Answer 1

Lamentablemente, no puedo responder adecuadamente a su pregunta, pero si mira los ejemplos de extensiones C# en el blog de Miguel de Icaza, notará que todos ellos toman la forma de parches para el compilador, no complementos o extensiones. Esto parece indicar que no existe tal API.

Tenga en cuenta que todos estos ejemplos son de alcance mucho más pequeña de lo que parece estar funcionando en:

• Parameterless Anonymous Methods (este post realmente menciona explícitamente las preocupaciones sobre la capacidad de mantenimiento de este tipo de extensiones de lenguaje)
• String Interpolation
• Destructuring Assignment for Tuples
• Syntactic Sugar for IEnumerable

Estos son principalmente azúcar sintáctico localizado, sin ningún comportamiento "interesante". El cuarto parche, por ejemplo, implementa el azúcar sintáctico de Cω para IEnumerable s, pero sin ninguna de las semánticas de Cω que hacen interesante esta sintaxis. Si nos fijamos en el parche, podemos ver que, literalmente, se trata de una estúpida expansión sintáctica de ~T → IEnumerable<T>, a diferencia de Cω, donde el acceso de los miembros y la invocación de métodos se levantan correctamente sobre las transmisiones.

Microsoft Research's Phoenix Compiler Pipeline una vez se promocionó explícitamente como la solución a tales problemas de extensibilidad, pero parece que ahora se centra principalmente en optimizaciones y análisis en el nivel IR en un backend de generación de código. De hecho, ni siquiera estoy seguro de si el proyecto aún está vivo.

Answer 2

El compilador mono C# es un poco hack. Pasé alrededor de una semana averiguando cómo usar la información del árbol de análisis sintáctico. El compilador no produce ninguna representación intermedia y la generación de código puede romper partes del árbol de análisis sintáctico. Aún así, el analizador y el tokenizador pueden serle útiles y solo lo toma desde allí. SharpDevelop también proporciona un C# parser. El analizador SharpDevelop es más fácil de usar que el analizador mono C#. Si F # también funciona para usted, lo recomendaría. La fuente es mucho más limpia que la mono y está disponible bajo licencia de fuente abierta.