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 个月后完成。语言的名字届时会最终确定。
评论