Расширение компилятора Mono C #: есть ли документация или прецедент?
====================================================================

В настоящее время я участвую в некоторых интересных исследованиях языка программирования, которые до сих пор были сосредоточены вокруг расширения грядущего компилятора Java 7.0 некоторыми очень мощными функциями, основанными на производительности программиста. Работа должна быть в равной степени применима к родственным языкам программирования, таким как C #.

В настоящее время я определяю параметры прототипирования порта C # функциональности. Я бы предпочел варианты с открытым исходным кодом, чтобы плоды этой работы можно было донести до максимально широкой аудитории. Таким образом, компилятор Mono C # кажется наиболее очевидной отправной точкой. Я опытный разработчик C #, поэтому написание кода не проблема. Я в основном обеспокоен расширением компилятора поддерживаемым и поддерживаемым способом. В моно FAQ по теме ([ссылка на сайт](https://www.mono-project.com/FAQ%3a_Technical)) утверждается, что «Mono уже использовался в качестве основы для опробования новых идей для языка C # (есть три или четыре компилятора, полученных из компилятора Mono C #)». К сожалению, нет никаких других указателей, кроме этого, и пока поиски в Google ничего не нашли.

Мне интересно, есть ли у кого-нибудь какая-либо информация по этому поводу. Делать`mcs`/`gmcs`/`dmcs` есть стандартная модель расширяемости? В частности, я буду выполнять некоторые интересные преобразования в абстрактном синтаксическом дереве программы. Существует ли стандартный механизм для вставки функциональности в цепочку компилятора между генерацией абстрактного синтаксического дерева и средством проверки типов, а затем генерацией кода?

До сих пор я написал несколько специальных расширений для кода (в основном в генераторе кода), но это не представляется приемлемым решением, особенно с учетом того, что я намерен поддерживать свои расширения в актуальном состоянии с помощью магистрали Git Моно как можно больше. Кроме того, было бы неплохо иметь возможность обновлять мои расширения без необходимости перекомпиляции всего компилятора каждый раз, когда я вносил изменения. Я хотел бы иметь возможность обернуть все мои манипуляции AST в одну сборку .NET, которая может быть динамически загружена`mcs`/`gmcs`/`dmcs` без необходимости взломать основной код компилятора напрямую.

Мы будем благодарны за любые мысли или советы по расширению компилятора Mono C #!

ОБНОВЛЕНИЯ (23 октября 2010 г.)

Отвечая на ответы на мой вопрос, я решил, что начну работать над веткой Mono, чтобы создать простую модель расширяемости для компилятора. Это на ранних стадиях, но здесь, на GitHub:

[http://github.com/rcook/mono-extensibility](https://github.com/rcook/mono-extensibility)

И основной коммит это:[http://github.com/rcook/mono-extensibility/commit/a0456c852e48f6822e6bdad7b4d12a357ade0d01](https://github.com/rcook/mono-extensibility/commit/a0456c852e48f6822e6bdad7b4d12a357ade0d01)

Если кому-то будет интересно сотрудничать в этом проекте, пожалуйста, дайте мне знать!

 я не могу адекватно ответить на ваш вопрос, но если вы посмотрите на примеры расширений C # в блоге Мигеля де Икаса, вы заметите, что все они принимают форму исправлений для компилятора, а не плагинов или расширений. Похоже, это указывает на то, что такого API нет.

Обратите внимание, что все эти примеры имеют гораздо меньшую область применения, чем то, над чем вы, кажется, работаете:

[Беспараметрические анонимные методы](https://themonkeysgrinder.blogspot.com/2009/07/cer.html) (этот пост на самом деле явно упоминает опасения по поводу возможности поддержки таких расширений языка)[Строковая интерполяция](http://tirania.org/blog/archive/2009/Dec-20.html)[Разрушающее задание для кортежей](http://tirania.org/blog/archive/2009/Dec-23.html)[Синтаксический сахар для`IEnumerable`](http://evain.net/blog/articles/2010/08/09/a-river-of-t)Это в основном локализованный синтаксический сахар, без «интересного» поведения. Четвертый патч, например, реализует синтаксический сахар Cω для`IEnumerable`s, но без какой-либо семантики Cω, которая делает этот синтаксис интересным. Если вы посмотрите на патч, вы увидите, что он буквально делает глупое синтаксическое расширение`~T` → `IEnumerable<T>`в отличие от Cω, где доступ к элементу и вызов метода должным образом подняты над потоками.

[Трубопровод компилятора Phoenix от Microsoft Research](https://connect.microsoft.com/Phoenix) Когда-то это явным образом рекламировалось как решение таких проблем с расширяемостью, но, похоже, сейчас оно сосредоточено в основном на оптимизации и анализе на уровне IR в бэкенде генерации кода. На самом деле, я даже не уверен, что проект еще жив.



 чтобы понять, как использовать информацию из дерева разбора. Компилятор не создает никакого промежуточного представления, и генерация кода может нарушить части дерева разбора. Тем не менее, парсер и токенизатор могут оказаться полезными для вас, и вы просто берете их оттуда. SharpDevelop также предоставляет[C # парсер](http://www.icsharpcode.net/OpenSource/SD/Default.aspx), Парсер SharpDevelop проще в использовании, чем моно парсер C #. Если F # также работает для вас, я бы порекомендовал. Исходный код намного чище моно и доступен по лицензии с открытым исходным кодом.