[翻译] .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
Tags:  CodePlex LISP LSharp Ikarus psyntax Xacc IronLisp IronScheme

延伸阅读

最新评论

发表评论