.NET 语言三剑客：IronScheme, IronLisp 和 Xacc

自从.NET DLR 发布之后，社区里大名鼎鼎的 Leppie，也就是 Llewellyn Pritchard，积极致力于将 Scheme 与 Lisp 集成到.NET DLR 中。最终的产品就是包含了集成开发环境的 IronScheme 与 IronLisp，它们极大地丰富了开发者的开发体验。最近，InfoQ 编辑有幸联系到了 Leppie，请他谈谈关于 IronScheme 与 IronLisp 的开发近况。

James：是什么动力促使你发布 IronScheme 的 1.0 版？

Leppie：在我编程生涯之初，就痴迷于语言这门技术。我最初知道的 LISP 语言是 LSharp 。我深深地为其所吸引，因此决定将其合并到我正在进行的项目 xacc.ide。最初的尝试是为 LSharp 创建一个编译器，但我总是无法成功，最后不得不放弃这样的努力。几年之后，我与 LSharp 的作者再次谈到开发一个 LSharp 编译器的想法，这次准备使用 LINQ（我始终认为 LINQ 非常适用于 Scheme，因为 Scheme 只要求一些基本的语法结构）。Rob Blackwell（LSharp 的作者）向我提到了他即将会为 LSharp 发布 DLR。这让我为之振奋，并决定等待它的发布。不到一个月的时间，DLR 发布了，而我则在第一时间对它进行了研究。我不曾真正给予 LSharp 任何创新的设计思想，只是试图基于 LSharp 进行开发。一个月后，我公开发布了 IronLisp，它是 LISP 的另外一种语言。它的发布对我而言可谓好坏参半。好处在于我通过社区获得了许多有价值的反馈，而坏处则是让我认识到了并没有人愿意再使用另一种 LISP 语言。在这个阶段，LSharp 为我展示了 LISP 语言的各种形式，同时还要感谢这些反馈，使得我开始引入 Scheme。IronScheme 几乎是对 IronLisp 的一次完整重写。其中蕴含的原因有好多，以下是我随便列出的几个。

• 需要遵循（或者尽量遵循）标准。我选择的是 Common LISP（CL）或 Scheme。我选择的 Sheme 语言规范（R5RS）只有大约 50 页，包含了数百个 procedures/constructs，而在 CL 中却有超过 1000 个。这种做法被证明是行之有效的，它使得我能够将注意力放在语言的核心部分，而不用去担心太多的细枝末节。目前，IronScheme 正试图遵循最近定稿的 R6RS 语言规范。它需要大约 700 个 constructs/procedures，是之前版本的近 3 倍。目前，IronScheme 已经完成 R6RS 相关内容的 80%-90%。
• IronLisp 存在几个设计缺陷是我无法进行修改和完善的，而这些存在缺陷的功能最主要的目的则是使得 IronLisp 能够更好地与 CLR 进行互操作。这是一个糟糕的错误，它会给 IronLisp 的发展带来负面的影响，而我却对此无能为力。
• 充分地吸取 IronLisp 的前车之鉴。

最初，我只是计划支持 R5RS，但是随着我对各种‘宏系统’的测试，我发现了 psyntax ，它提供了 Scheme 共同体，该共同体包含了一个针对语法与库系统的引用实现。让我惊讶的是，IronScheme 可以毫无障碍地“吞”下引导代码（Bootstrap Code，这种代码针对于另外一种 Schema 而实现，我认为是 Kawa），这就给了我一个 R6RS 实现的绝佳模板。由于 psyntax 友好地为几乎所有的 Scheme‘宏’提供了实现，其中，只有几个核心宏、过程与语义是必须被实现的，这包括一个 reader/parser（无论何时它都属于语言规范的组成部分）。它的出彩之处在于它能够很好地与 CLR 的方法相匹配，因此，大多数库代码都可以用 C#编写，虽然我希望在将来能够将它们所有都包含在 Scheme 中（我对于编写 Scheme 的有限经验使得这一部分内容被抽取出来，但这一过程仍然具有挑战性）。

另一个重要的灵感则来自于 Abdulaziz Ghuloum，他是 psyntax 的其中一个作者，也是 Ikarus 的作者，Ikarus 是一个全新的遵循 R6RS 的 Scheme，它具有一个极富冲击力的实现方式。目前，它的运行速度比 IronScheme 快 10-50 倍。

James：谁是 IronScheme 的目标用户。

Leppie：由于 IronScheme 试图遵循 R6RS 语言规范，大多数可移植的程序都能够无障碍地运行。我无法确定我的目标用户是哪些，但我知道应该是像我这样熟悉 Ruby 或者 Python，但同时又具有很强的.NET 背景的开发者。他们应该能发现我的工作所带来的价值。同时，Scheme 也被频繁应用于学术教育领域。看到 IronScheme 正在被应用到学院和大学教育中，真是太棒了。

另一些潜在用户包括那些希望将一种通用的脚本语言集成在他们的应用程序中的开发者，但是通常情况下，最终用户会发现 Python 或者类似于 JavaScript 的语言会更加地容易。对于我自己而言，它将会取代 xacc.ide 中的 LSharp。IronScheme 是开源的，托管在 CodePlex 上。

James：在过去，DLR 的变化已经影响到了动态语言，那么你对于 IronScheme 与 IronLisp 的经验又是什么呢？

Leppie: 因为这一巨大的变化，我在两个月前停止了对我的 DLR 的开发。这一变化不仅仅影响了动态语言的功能，还影响了它的接口。库的结构 / 命名都发了重大的变化，同时还增加或移除了许多功能特性。这使得我很难协调自己的修改，例如我需要修复一些 bug，也需要添加一些 DLR 不具备的功能（例如 tail calls，direct method references 以及创建 persisted assemblies 和 performance hacks 的能力）。目前，IronScheme 仅仅使用了 DLR 的 20%（视 NCover 而定）。或许我们值得从头开始对编写 code-generation 库的可行性进行研究（或许仅将 DLR 当作是一个 bootstrap，用 Scheme 自身进行编写）。

一件可能很有价值的事是他们是否积极地更新在 CodePlex 上的源代码（译者注：这里指 DLR 的源代码），但是现在看来似乎只是时不时的进行更新。

James：IronScheme 的下一个版本会包含哪些功能特征？

Leppie：由于 1.0 版本主要集中在尽可能地多地遵循 R6RS，因此后面的版本主要会专注于性能的优化以及提供 Scheme 和 CLR 之间更好的交互。同时，由于 CLR 并不支持任意精度的数字，因此还会增加这一功能（使用 GMP）。DLR 只支持（大的）整数。

我还需要突破几个局限，以能够 100% 的实现兼容，其中最重要的是要实现 Continuation（译者注：Continuation 是一种编程概念和函数调用方式，可以参看这篇博客园文章 的解释）。目前的IronScheme 只支持对非本地返回值的’对外’的Continuation。这种方式也被用于JVM 中。我最近看了一些IronRuby 开发者对于此的实现方式，在他们的代码中，callcc 也仅仅是作为注释而存在。 James：IronLisp 的下一个版本会包含哪些功能特征？

Leppie：我不认为还有发展 IronLisp 的必要，除非有人愿意接手它。最好是使用 IronScheme 作为 IronLisp 未来版本的基础。

James：是什么促使你创建 xacc 项目？

Leppie：我需要一个 MSIL 编辑器。我尝试使用了 VS2003 中的 VSIP 包，但我很不喜欢整个都是 C++ 的内容，因而我又试用了 SharpDevelop。

遗憾地是，他们的编辑器写得并不够好（至少在当时是如此）。大约在一个月后，SharpDevelop 团队拒绝了我提出的几个建议，因此我决定 $^%&^& 他们，开始自己编写一个，而且可以写得比其它编辑器都好。这正是（并无双关语意）我四年前所做的。xacc 支持 XML 特性的编译器。我希望能够开发一个程序，在其中你可以设计自己的语言，同时又能够拥有一个针对它的编辑器。我实在是过于低估了这一概念所包含的范畴，因此直到现在这一编辑器也只能有限地支持开发者添加新的语言。通过 xacc，可以在 30 分钟之内添加任何一种语言基本语法的高亮显示。你也可以进一步合并一个解析器以实现语法检查、括号匹配和区域折叠。你甚至可以为你的语言创建一个‘AST’，并在导航条与大纲视图上显示它。上述功能甚至可以被 AutoCompletion（自动完成）所使用（但实现得并不够好）。最后，你可以利用 MSBuild 文件以创建一个项目。目前 C#和 Scheme 使用了这一设计的大多数功能，而大约有 20 种其它的基于.NET 的语言仅仅使用了语法高亮显示的功能。

经过 4 年的开发，这个包含了众多功能特征的编辑器变得更加轻便、快捷，以及易于定制。最新版本的安装文件刚刚超过 600k 字节，它包含了 C#的语法高亮显示，并且能够匹配 VS2008 具有的渲染质量，尤其在编辑大文件（10k 行或者更多）上优势明显。（有趣的是，VS2003 对于大文件的处理优于之后的 VS 新版本）。遗憾的是，由于开发周期的问题，有一些使用频率较低的功能特性，例如调试（degugging）以及项目支持（project support）遇到了一些问题，无法正常工作。然而，这些特性在我的工作列表中是属于优先级较低的。

James：社区对 xacc 的反应怎么样呢？

Leppie：很遗憾，社区的反应并不热烈。如果不考虑我所依赖的程序（以及其他‘插件’代码），我就是 xacc.ide 唯一的开发者（IronScheme 同样如此）。如果说我是唯一的用户，我也不会感到惊讶:) 从另一个角度讲，这反而给了我更多便利，因为我可以随时终止或者开始我的项目，而不会陷入到无穷无尽的 bug 报告或特性需求的泥潭之中。

James：自从你更新了 xacc 之后，差不多过了 2 年时间了，最近有没有什么发布计划？

Leppie：SourceForge 上的“最新新闻”可能已经有些陈旧了，但是事实上 xacc.ide 仍然处于开发进程中（其间有 6 个月的临时中断）。事实上，项目从来没有完成我所期望达到的目标，总是有更多的事情需要去做。最近，我发布了几个版本（更接近于 SVN 构建版本的概念）以支持 IronScheme，很快还会有更多内容会发布。我拥有一个版本发布的 RSS 种子 ，启动时 xacc.ide 会检查是否有新版本发布。

现在，在 CodePlex 上有关于IronScheme 最近的信息 ，它的进度已经接近1.0 版本。衷心感谢Leppie 接受InfoQ 的这次采访，希望大家能够在.NET 动态语言栏目中获得更多精彩的内容。

查看英文原文： A .NET Triumvirate: IronScheme, IronLisp, and Xacc

译者介绍：张逸（Bruce Zhang），毕业于四川大学计算机学院，文学爱好者，微软最有价值专家（MVP）。曾先后任职中兴通讯重庆研究所以及惠普 GDCC。拥有 10 年左右的软件开发与 5 年左右的软件架构设计经验，熟悉 C#，ASP.NET，Web Service，.NET Remoting，WCF 等技术。在面向对象领域具有一定造诣，特别是设计模式、测试驱动开发、极限编程与 UML 等技术与思想的运用。目前，主要从事 SOA 企业信息解决方案的设计与研究。著作 / 译作包括《软件设计精要与模式》、《WCF 服务编程》。他的个人主页为 http://www.brucezhang.com 。