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

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

15 голосов
/ 03 октября 2010

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

В настоящее время я определяю параметры прототипирования порта C # функциональности. Я бы предпочел варианты с открытым исходным кодом, чтобы плоды этой работы можно было донести до максимально широкой аудитории. Таким образом, компилятор Mono C # кажется наиболее очевидной отправной точкой. Я опытный разработчик C #, поэтому написание кода не проблема. Я в основном обеспокоен расширением компилятора поддерживаемым и поддерживаемым способом. В Mono FAQ по этому вопросу ( ссылка ) говорится, что «Mono уже использовался в качестве основы для опробования новых идей для языка C # (есть три или четыре компилятора, полученных из компилятора Mono C #). )». К сожалению, нет никаких других указателей, кроме этого, и пока поиски в Google ничего не нашли.

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

До настоящего момента я написал несколько специальных расширений для кода (в основном в генераторе кода), но это не представляется приемлемым решением, особенно с учетом того, что я намерен поддерживать свои расширения в актуальном состоянии с помощью Дробить багажник от моно как можно больше. Кроме того, было бы неплохо иметь возможность обновлять мои расширения без необходимости перекомпиляции всего компилятора каждый раз, когда я вносил изменения. Я хотел бы иметь возможность обернуть все мои манипуляции с 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

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

Ответы [ 2 ]

3 голосов
/ 09 октября 2010

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

3 голосов
/ 03 октября 2010

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

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

Это в основном локализованный синтаксический сахар, без "интересного" поведения. Четвертый патч, например, реализует синтаксический сахар Cω для IEnumerable s, но без какой-либо семантики Cω, которая делает этот синтаксис интересным. Если вы посмотрите на патч, вы увидите, что он буквально делает глупое синтаксическое расширение ~T & rarr; IEnumerable<T>, в отличие от Cω, где доступ к элементу и вызов метода правильно подняты над потоками.

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

...