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

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

В настоящее время я определяю параметры прототипирования порта C # функциональности. Я бы предпочел варианты с открытым исходным кодом, чтобы плоды этой работы можно было донести до максимально широкой аудитории. Таким образом, компилятор Mono C # кажется наиболее очевидной отправной точкой. Я опытный разработчик C #, поэтому написание кода не проблема. Я в основном обеспокоен расширением компилятора поддерживаемым и поддерживаемым способом. В моно FAQ по теме (ссылка на сайт) утверждается, что «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

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

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

 Jordão03 окт. 2010 г., 04:37
В качестве альтернативы, посмотрите наБу, Расширяемость компилятора является частью «пакета».

Ответы на вопрос(2)

Решение Вопроса

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

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

Беспараметрические анонимные методы (этот пост на самом деле явно упоминает опасения по поводу возможности поддержки таких расширений языка)Строковая интерполяцияРазрушающее задание для кортежейСинтаксический сахар дляIEnumerable

Это в основном локализованный синтаксический сахар, без «интересного» поведения. Четвертый патч, например, реализует синтаксический сахар Cω дляIEnumerables, но без какой-либо семантики Cω, которая делает этот синтаксис интересным. Если вы посмотрите на патч, вы увидите, что он буквально делает глупое синтаксическое расширение~TIEnumerable<T>в отличие от Cω, где доступ к элементу и вызов метода должным образом подняты над потоками.

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

 Jordão03 окт. 2010 г., 04:38
Вы можете найти еще один маленький патчВот, Может быть, это хорошо, чтобы создать каталог этих патчей.
 Richard Cook24 окт. 2010 г., 01:46
Я начал работать над веткой расширяемости:github.com/rcook/mono-extensibility/commit/...
 Richard Cook03 окт. 2010 г., 17:13
и @ Jordão: +1 каждый за ваши полезные ссылки. В интересах обмена вот ссылка на мой личный пост в блоге:clopenset.com/content/..., Прикрепленный патч - это простой хак, позволяющий использовать инструментарий тел методов, который несколько отличается от модификаций AST / проверки типов, которые я планирую сделать, но, тем не менее, был интересным экспериментом.

чтобы понять, как использовать информацию из дерева разбора. Компилятор не создает никакого промежуточного представления, и генерация кода может нарушить части дерева разбора. Тем не менее, парсер и токенизатор могут оказаться полезными для вас, и вы просто берете их оттуда. SharpDevelop также предоставляетC # парсер, Парсер SharpDevelop проще в использовании, чем моно парсер C #. Если F # также работает для вас, я бы порекомендовал. Исходный код намного чище моно и доступен по лицензии с открытым исходным кодом.

 Richard Cook24 окт. 2010 г., 01:46
Я сам взломал и согласен с вашими оценками. Я все равно решил его разветвить:github.com/rcook/mono-extensibility/commit/...

Ваш ответ на вопрос