Rozszerzanie kompilatora Mono C#: czy istnieje jakakolwiek dokumentacja lub precedens?

Question

Obecnie jestem zaangażowany w interesujące badania języka programowania, które do tej pory koncentrowały się na rozszerzaniu nadchodzącego kompilatora Java 7.0 z kilkoma bardzo potężnymi funkcjami opartymi na programatorze. Praca powinna mieć również zastosowanie do powiązanych języków programowania, takich jak C#.

Obecnie wybieram opcje prototypowania portu C# funkcjonalności. Wolałbym opcje open-source, aby owoce tej pracy mogły być udostępniane jak najszerszej publiczności. Tak więc kompilator Mono C# wydaje się najbardziej oczywistym punktem wyjścia. Jestem doświadczonym programistą C#, więc pisanie kodu nie jest problemem. Głównie martwię się o rozszerzenie kompilatora w sposób obsługiwany i obsługiwany. W Mono FAQ na ten temat (link) stwierdza się, że "Mono został już użyty jako podstawa do wypróbowania nowych pomysłów na język C# (istnieją trzy lub cztery kompilatory pochodzące z kompilatora C# Mono)". Niestety, nie ma żadnych dodatkowych wskazówek, a jak dotąd wyszukiwarki Google niczego nie zmieniły.

Zastanawiam się, czy ktoś tam ma jakieś informacje na ten temat. Czy model mcs/gmcs/dmcs ma standardowy model rozszerzalności? Dokładniej, przeprowadzę interesujące transformacje na abstrakcyjnym drzewie składni programu. Czy istnieje standardowy mechanizm wstawiania funkcjonalności do łańcucha kompilatora między generowaniem abstrakcyjnego drzewa składni a sprawdzaniem typu, a następnie generowaniem kodu?

Do tej pory napisałem kilka rozszerzeń ad-hoc do kodu (głównie w generatorze kodu), ale to nie wydaje się być rozwiązaniem możliwym do utrzymania, zwłaszcza, że ​​zamierzam aktualizować moje rozszerzenia o bagażnik Git Mono jak najwięcej. Ponadto byłoby miło móc aktualizować moje rozszerzenia bez konieczności ponownej kompilacji całego kompilatora za każdym razem, gdy dokonuję zmiany. Chciałbym móc zawrzeć wszystkie moje manipulacje AST w jednym zestawie .NET, który mógłby być dynamicznie ładowany przez mcs/gmcs/dmcs bez konieczności włamywania się bezpośrednio do głównego kodu kompilatora.

Wszelkie myśli i wskazówki dotyczące rozszerzania kompilatora Mono C# zostałyby przyjęte z wdzięcznością!

aktualizacji (23 października 2010)

W odpowiedzi na odpowiedzi na moje pytanie, postanowiłem, że chciałbym zacząć pracę na oddziale Mono w celu stworzenia prostego modelu rozciągliwości dla kompilatora. To w jej bardzo wczesnym stadium, ale tutaj jest na GitHub:

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

A głównym popełnić to: http://github.com/rcook/mono-extensibility/commit/a0456c852e48f6822e6bdad7b4d12a357ade0d01

Jeśli ktoś byłby zainteresowany współpracą przy tym projekcie, proszę dać mi znać!

Answer 1

Niestety, nie mogę odpowiedzieć na twoje pytanie, ale jeśli spojrzysz na przykłady rozszerzeń C# na blogu Miguel de Icaza, zauważysz, że wszystkie one mają postać łatek do kompilatora, a nie wtyczek czy rozszerzeń. Wydaje się to wskazywać, że nie ma takiego API.

pamiętać, że wszystkie te przykłady są znacznie mniejszym zakresie niż to, co wydaje się działać na:

• Parameterless Anonymous Methods (Ten post rzeczywiście wyraźnie wymienia obawy o konserwacji takich rozszerzeń języka)
• String Interpolation
• Destructuring Assignment for Tuples
• Syntactic Sugar for IEnumerable

Są to głównie zlokalizowane cukry syntaktyczne, bez "interesującego" zachowania. Czwarta łatka, na przykład, implementuje syntaktyczny cukier Cω dla IEnumerable s, ale bez żadnej semantyki Cω, która czyni tę składnię interesującą. Jeśli spojrzysz na łatkę, zobaczysz, że dosłownie robi ona głupią syntaktyczną ekspansję w stosunku do Cω, gdzie dostęp do elementu i wywołanie metody są poprawnie podnoszone przez strumienie.

Microsoft Research's Phoenix Compiler Pipeline był kiedyś wyraźnie reklamowany jako rozwiązanie takich problemów z rozszerzalnością, ale wydaje się, że obecnie koncentruje się głównie na optymalizacjach i analizie na poziomie IR w backendach generowania kodu. W rzeczywistości nie jestem nawet pewien, czy projekt jest jeszcze żywy.

Answer 2

Kompilator mono C# jest trochę hackerem. Spędziłem około tygodnia, zastanawiając się, jak wykorzystać informacje z drzewa parse. Kompilator nie generuje pośredniej reprezentacji, a generowanie kodu może uszkodzić części drzewa analizy. Mimo to parser i tokenizer mogą ci się przydać, a ty po prostu je zabierz. SharpDevelop zapewnia również C# parser. Parser SharpDevelop jest łatwiejszy w użyciu niż parser mono C#. Jeśli F # działa również dla Ciebie, poleciłbym. Źródło o wiele czystsze niż mono i dostępne na licencji open source.