Erweitern des Mono C# -Compilers: Gibt es Dokumentation oder Präzedenzfälle?

Question

Ich bin zur Zeit an einer interessanten Programmiersprachenforschung beteiligt, die sich bis jetzt auf die Erweiterung des kommenden Java 7.0 Compilers mit einigen sehr leistungsfähigen Programmer-produktivitätsbasierten Funktionen konzentrierte. Die Arbeit sollte gleichermaßen auf verwandte Programmiersprachen wie C# anwendbar sein.

Ich bin derzeit dabei, die Optionen für das Prototyping eines C# -Ports der Funktionalität auszuloten. Ich würde Open-Source-Optionen bevorzugen, damit die Früchte dieser Arbeit mit einem möglichst breiten Publikum geteilt werden können. Daher scheint der Mono C# -Compiler der offensichtlichste Ausgangspunkt zu sein. Ich bin ein erfahrener C# -Entwickler, also ist das Schreiben des Codes nicht das Problem. Ich bin hauptsächlich besorgt darüber, den Compiler in einer wartbaren und unterstützten Weise zu erweitern. In den Mono-FAQ zum Thema (link) heißt es: "Mono wurde bereits als Grundlage für das Ausprobieren neuer Ideen für die C# -Sprache verwendet (es gibt drei oder vier Compiler, die von Monos C# -Compiler abgeleitet sind)." Leider gibt es keine weiteren Hinweise und die Google-Suche hat bis jetzt noch nichts gebracht.

Ich frage mich, ob jemand da draußen irgendwelche Informationen dazu hat. Haben mcs/gmcs/dmcs ein Standard-Erweiterbarkeitsmodell? Insbesondere werde ich einige interessante Transformationen im abstrakten Syntaxbaum eines Programms durchführen. Gibt es einen Standardmechanismus zum Einfügen von Funktionen in die Compiler-Kette zwischen der Generierung von abstrakten Syntaxbäumen und dem Typ-Checker und der anschließenden Code-Generierung?

Bis jetzt habe ich einige Ad-hoc-Erweiterungen für den Code geschrieben (hauptsächlich im Code-Generator), aber das scheint keine wartbare Lösung zu sein, vor allem, wenn ich meine Erweiterungen auf dem neuesten Stand halten will der Git Stamm von Mono so viel wie möglich. Außerdem wäre es schön, Updates für meine Erweiterungen vornehmen zu können, ohne den Compiler bei jeder Änderung neu kompilieren zu müssen. Ich möchte in der Lage sein, alle meine AST-Manipulationen in eine einzelne .NET-Assembly zu verpacken, die von mcs/ dynamisch geladen werden kann, ohne direkt den Kern-Compiler-Code hacken zu müssen.

Alle Gedanken oder Hinweise zur Erweiterung des Mono C# -Compilers würden dankbar empfangen werden!

UPDATES (23 Oktober 2010)

Als Antwort auf die Antworten auf meine Frage, habe ich beschlossen, dass ich auf einem Zweig der Mono arbeiten, um beginnen würde, eine einfache Erweiterungsmodell für den Compiler zu erstellen. Es ist in einem sehr frühen Stadium, aber hier ist es bei GitHub:

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

Und die Haupt begehen: http://github.com/rcook/mono-extensibility/commit/a0456c852e48f6822e6bdad7b4d12a357ade0d01

Wenn jemand in der Zusammenarbeit an diesem Projekt interessiert wäre, lassen Sie es mich wissen!

Answer 1

Leider kann ich Ihre Frage nicht ausreichend beantworten, aber wenn Sie sich die Beispiele von C# -Erweiterungen auf Miguel de Icazas Blog ansehen, werden Sie feststellen, dass sie alle die Form von Patches für den Compiler haben, keine Plugins oder Erweiterungen. Dies scheint darauf hinzuweisen, dass es keine solche API gibt.

Beachten Sie, dass alle diese Beispiele von viel kleineren Umfang sind als das, was Sie scheinen zu arbeiten:

• Parameterless Anonymous Methods (Dieser Beitrag ist eigentlich ausdrücklich erwähnt Bedenken über die Wartbarkeit solcher Spracherweiterungen)
• String Interpolation
• Destructuring Assignment for Tuples
• Syntactic Sugar for IEnumerable

Dies sind meist lokalisierte syntaktische Zucker, ohne "interessantes" Verhalten. Der vierte Patch implementiert zum Beispiel den syntaktischen Zucker von C & ohgr; für IEnumerable s, aber ohne irgendeine der Semantiken von C & ohgr ;, die diese Syntax interessant macht. Wenn Sie sich das Patch ansehen, können Sie sehen, dass es im Gegensatz zu Cω buchstäblich eine dumme syntaktische Erweiterung von ~TIEnumerable<T> ist, wobei der Zugriff von Mitgliedern und der Aufruf von Methoden ordnungsgemäß über Streams aufgehoben werden.

Microsoft Research's Phoenix Compiler Pipeline wurde einst ausdrücklich als Lösung für solche Erweiterbarkeitsprobleme angepriesen, aber es scheint, dass es sich jetzt hauptsächlich auf Optimierungen und Analysen auf der IR-Ebene in einem Code-Generierungs-Backend konzentriert. In der Tat bin ich nicht einmal sicher, ob das Projekt überhaupt noch am Leben ist.

Answer 2

Der Mono-C# -Compiler ist ein bisschen wie ein Hack. Ich habe ungefähr eine Woche damit verbracht, herauszufinden, wie man Informationen aus dem Parse-Baum benutzt. Der Compiler erzeugt keine Zwischenrepräsentation, und die Codegenerierung kann Teile des Syntaxbaums zerstören. Dennoch können sich der Parser und der Tokenizer für Sie als nützlich erweisen und Sie nehmen ihn einfach von dort. SharpDevelop bietet auch eine C# parser. Der SharpDevelop-Parser ist einfacher zu verwenden als der Mono-C# -Parser. Wenn F # auch für dich funktioniert, würde ich empfehlen. Die Quelle ist viel sauberer als Mono und unter Open-Source-Lizenz verfügbar.