扩展 Mono C# 编译器:是否有任何文档或先例? [英] Extending the Mono C# compiler: is there any documentation or precedent?

查看:37
本文介绍了扩展 Mono C# 编译器:是否有任何文档或先例?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前参与了一些有趣的编程语言研究,到目前为止,该研究的重点是扩展即将推出的 Java 7.0 编译器,并提供一些非常强大的基于程序员生产力的功能.这项工作应该同样适用于相关的编程语言,例如 C#.

I am currently involved in some interesting programming language research which has, up until now, centred around extending the upcoming Java 7.0 compiler with some very powerful programmer-productivity-based features. The work should be equally applicable to related programming languages such as C#.

我目前正在确定用于对功能的 C# 端口进行原型设计的选项.我更喜欢开源选项,以便可以与最广泛的受众分享这项工作的成果.因此,Mono C# 编译器似乎是最明显的起点.我是一位经验丰富的 C# 开发人员,因此编写代码不是问题.我主要关心以可维护和受支持的方式扩展编译器.在有关该主题的 Mono 常见问题解答(link)中声明Mono 已经用作尝试 C# 语言新想法的基础(从 Mono 的 C# 编译器派生的三个或四个编译器)".不幸的是,没有比这更进一步的指示,而且到目前为止,谷歌搜索还没有出现任何结果.

I'm currently scoping out the options for prototyping a C# port of the functionality. I would prefer open-source options so that the fruits of this work can be shared with the broadest-possible audience. Thus the Mono C# compiler seems to be the most obvious starting point. I'm an experienced C# developer so writing the code isn't the problem. I'm mainly concerned about extending the compiler in a maintainable and supported fashion. In the Mono FAQ on the subject (link) it is stated that "Mono has already been used as a foundation for trying out new ideas for the C# language (there are three or four compilers derived from Mono's C# compiler)". Unfortunately, there are no further pointers than this and, so far, Google searches have not turned anything up.

我想知道有没有人有这方面的信息.mcs/gmcs/dmcs 有标准的可扩展模型吗?具体来说,我将对程序的抽象语法树进行一些有趣的转换.是否有一种标准机制可以在抽象语法树生成和类型检查器然后代码生成之间将功能插入到编译器链中?

I'm wondering if anybody out there has any information on this. Do mcs/gmcs/dmcs have a standard extensibility model? Specifically, I will be performing some interesting transformations on a program's abstract syntax tree. Is there a standard mechanism for inserting functionality into the compiler chain between abstract syntax tree generation and the type checker and then code generation?

到目前为止,我已经为代码编写了一些临时扩展(主要在代码生成器中),但这似乎不是一个可维护的解决方案,特别是考虑到我打算让我的扩展与尽量使用 Mono 的 Git 主干.此外,能够在每次进行更改时不必重新编译整个编译器的情况下对我的扩展进行更新会很好.我希望能够将我所有的 AST 操作包装到单个 .NET 程序集中,该程序集可以由 mcs/gmcs/dmcs 动态加载无需直接破解核心编译器代码.

Up until now I've written some ad-hoc extensions to the code (primarily in the code generator) but this doesn't seem to be a maintainable solution especially given that I intend to keep my extensions up to date with the Git trunk of Mono as much as possible. Furthermore it would be nice to be able to make updates to my extensions without having to recompile the whole compiler every time I make a change. I would like to be able to wrap all my AST manipulations into a single .NET assembly that could be dynamically loaded by mcs/gmcs/dmcs without having to hack at the core compiler code directly.

任何关于扩展 Mono C# 编译器的想法或建议都将不胜感激!

Any thoughts or pointers on extending the Mono C# compiler would be gratefully received!

更新(2010 年 10 月 23 日)

UPDATES (23 October 2010)

针对我的问题的回答,我决定开始研究 Mono 的一个分支,以便为编译器创建一个简单的可扩展性模型.它处于非常早期的阶段,但它位于 GitHub:

In response to the responses to my question, I decided that I would start working on a branch of Mono in order to create a simple extensibility model for the compiler. It's in its very early stages, but here it is at GitHub:

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

主要提交是:http://github.com/rcook/mono-可扩展性/提交/a0456c852e48f6822e6bdad7b4d12a357ade0d01

如果有人有兴趣在这个项目上合作,请告诉我!

If anybody would be interested in collaborating on this project, please let me know!

推荐答案

很遗憾,我无法充分回答您的问题,但是如果您查看 Miguel de Icaza 博客上的 C# 扩展示例,您会发现它们都采用编译器的补丁形式,而不是插件或扩展.这似乎表明没有这样的 API.

Unfortunately, I cannot adequately answer your question, but if you look at the examples of C# extensions on Miguel de Icaza's blog, you will notice that all of them take the form of patches to the compiler, not plugins or extensions. This seems to indicate that there is no such API.

请注意,所有这些示例的范围都比您似乎正在研究的范围小得多:

Note that all of these examples are of much smaller scope than what you seem to be working on:

  • Parameterless Anonymous Methods (this post actually explicitly mentions concerns about the maintainability of such language extensions)
  • String Interpolation
  • Destructuring Assignment for Tuples
  • Syntactic Sugar for IEnumerable

这些大多是本地化的语法糖,没有有趣"的行为.例如,第四个补丁为 IEnumerable 实现了 Cω 的语法糖,但没有任何使该语法有趣的 Cω 语义.如果您查看补丁,您会发现它确实对 ~T 进行了愚蠢的语法扩展 →IEnumerable<T>,与 Cω 相反,其中成员访问和方法调用被正确地提升到流上.

These are mostly localized syntactic sugar, with no "interesting" behavior. The fourth patch, for example, implements Cω's syntactic sugar for IEnumerables, but without any of Cω's semantics that make this syntax interesting. If you look at the patch you can see that it literally does stupid syntactical expansion of ~TIEnumerable<T>, as opposed to Cω, where member access and method invocation are properly lifted over streams.

Microsoft Research 的 Phoenix Compiler Pipeline 曾被明确吹捧为此类可扩展性问题的解决方案,但似乎它现在主要关注代码生成后端中 IR 级别的优化和分析.事实上,我什至不确定这个项目是否还活着.

Microsoft Research's Phoenix Compiler Pipeline was once explicitly touted as the solution to such extensibility problems, but it seems that it now focuses mostly on optimizations and analysis on the IR level in a code generation backend. In fact, I'm not even sure if the project is even still alive.

这篇关于扩展 Mono C# 编译器:是否有任何文档或先例?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆