Scheme 指导委员会(The Scheme Steering Committee)提议将Scheme 语言一分为二,并且将其名称暂定为小型(Small)Scheme 和大型(Large)Scheme。
由 Guy L. Steele 和 Gerald Jay Sussman 于 70 年代发明的 Scheme,最初作为 Lisp 的方言,到今天已经历经了数次修订。 IEEE 1178-1190 Standard 正式定义了 Scheme 的标准,但现实中使用的标准却是 Revisedn Report on the Algorithmic Language Scheme(简称为 RnRS)。其最新版本 R6RS 是 2007 年通过的。考虑到“编程语言就像鲨鱼一样,不动则亡”,Scheme 指导委员会决定继续推动该语言的发展。
委员会提到的主要问题在于,Scheme 并不是真正意义上的编程语言,而是
一系列方言的汇集。它们通过一组共同的特性彼此关联,这些特性包括:词法空间、动态类型、list 结构、高阶函数、尾递归、垃圾回收、宏以及(一定程度上的)基于词汇语法的 S- 表达式。
的确如此,Wikipedia 列出了大量的 Scheme 语言实现: Bigloo , Chez Scheme , Chicken , Gambit , Gauche , Guile , Ikarus , JScheme , Kawa , Larceny , MIT/GNU Scheme , Mosh , PLT Scheme , Pvts , RScheme , Scheme 48 , SCM , SISC , Stalin , STk , STklos , TinyScheme , Ypsilon 。根据 Scheme 委员会的报告内容,这些方言的问题在于:
如果程序员需要使用“Scheme”编写一段关键的程序,他就必然受制于某些特定的 Scheme 实现:Bigloo,say(以及其模块语言、异常系统、S- 表达式文法等等),PLT Scheme(以及其模块语言等等),或者其他任何一种可胜任于工程的实现。不过,这意味着应用程序无法跨多个实现执行。更重要的是,库和代码模块,比如 URL 解析器,网络协议栈,正则表达式实现等等,都被限制在某一个特定的实现,Scheme 程序员通常要从头开始做一件事情,而不能从其他人的劳动成果中获得益处。
最终导致的结果是,
后来的程序员无法站在以前程序员的肩膀上,而是制造了大量无用的片段和重复。Scheme 程序员之间要彼此重复。
委员会考虑到了 Scheme 语言的分裂,来自于各方面的关注者: 教育工作者,语言工作者,程序员,程序库实现者以及 Scheme 的粉丝。为了解决这个问题,委员会提出了两种独立但彼此兼容的语言。
小型 Scheme
- 关注者:教育工作者,非正式的库实现者,研究人员,嵌入式语言和“50-page” 语言纯粹主义者
- 考虑将“IEEE/R5RS 更新到最新状态”
- ~ 90% 需要等待最终批准
大型 Scheme
- 关注者:程序员,程序库实现者
- 考虑“优化 R6RS”
- ~ 75% 需要等待最终批准
指导委员会并不打算标准化语言,而是
确保Scheme 社区能够继续发展这门语言——它的定义,成长,扩展,标准化和实现。我们的机制是将权利赋予不同的委员会,由他们执行实际的工作,然后由我们收集并认可他们的工作。
两个工作组已经开始起草文档 Small Scheme Group 和 Large Scheme Group 。但是两个工作组至今还没有会员。小型 Scheme 的目的描述如下:
该小型语言包含了 Scheme 的基础特性。它的目标用途包含教育,程序设计语言研究,小型嵌入式系统,嵌入式脚本语言(其适合于在语义级别以及 / 或者实现级别使用某种轻量级语言)。
大型 Scheme 的草案则描述如下,
该大型语言需要解决主流软件开发中的实际问题…
由第二工作组开发的语言必须支持宏、模块和库。
一旦确定了包含哪些特性以后,第二工作组应该考虑 R6RS 包含的所有 Scheme 特性以及对这些特性的评价。
第二工作组也要考虑加入其他新特性是否可行,比如支持网络、线程、国际化,外部功能接口,等等。第二工作组也在积极地推荐新的工作组来负责其他新特性。这些特性都是倍受期待的,但是如果全部由第二工作组负责的话有可能影响他们的主要任务。
两个工作组正在协调彼此的工作,小型 Scheme 的最终提案将会在 18 个月后完成,大型 Scheme 的会在 25 个月后完成。语言的名字届时会最终确定。
评论