在经历了从blog到mailing list的腥风血雨之后，New Groovy的Roadmap粉墨登场。一定程度上这是对最近一段时间尘嚣甚上的Groovy is dead的回应。另一方面，Groovy的苦谏者Mike Spille对于新Groovy特性的批评所得到的回应却是以wiki形式确定下来的文档。
所有新特性中争议最大的，当然就是此条：return/break/continue to behave inside closures like these statements work in other blocks (such as the block on a for() or while() loop.
简而言之，这就是统一block和closure。
这里我忍不住王婆卖瓜一下，其实我已经直觉出这个味道。我在1月16日在groovy-dev上re了Mike Spille一篇：
I think we should regard foo() {} as syntax-sugar, this feature eliminate the difference between built-in flow structure and user-defined method call.
If = { condition, doSth | if (condition) doSth() }
t = { println 'Hello!' }
if (true) { println 'Hello!' } // built-in if
If (true) { println 'Hello!' } // user-defined If is similar to
built-in if, that's groovy!
If(true, t) // normal method call
If(true, { println 'Hello!' }) // normal method call even the last
param is a anonymous closure
>
> The puzzling errors bit is also why I favor a keyword for closures. It'll
> not only greatly simplify the grammar and parser, but I think it's better
> for users too. It clearly signals where closures are in your code, and
> avoids the problems of _users_ not knowing when they have a closure and
> when they have a block.
I think there is no essential difference between closure and block. User have a block, then want to reuse the block. make the block can be passed or returned or parameterized --- that is closure.
现在看来，当时我已经接近摆脱最初仅仅视closure为javascript中anonymous function等价物的想法了。我已经直觉到此closure与一般block之间的微妙关系。
closure的syntax很大程度上消除了内建流程结构和用户定义方法的区别。换言之，我们可以很方便的写出接受closure参数的方法，使得其调用语法能非常类似while, when（不带else的if）的语法结构！虽然还是无法复制for(;;)和if-else这样特殊的语法构造，但这已经是很大的震撼。
进而，我发现，就应用程序员角度而言，block和closure并不存在本质区别。block可以看作一个代码段，而closure是可以重用（可传递、返回以及参数化）的代码段。
然而closure和传统flow控制具有一定的冲突，这主要表现在如何实现break、continue语义。之前的建议一般是要求closure返回一个特定常量标记如Closure.BREAK来指示，然后由closure的调用者负有责任来处理此标志。
更大的问题在于，同样作为代码功能抽象和复用的单位，closure与function(method)发生了冲突。这就是要命的return问题！
显然，按照一般思路，closure在底层就是一个function或者说method，匿名closure形同block的 { param | expression } 的简洁构造可被视作一种语法sugar。并且从最初一直到现在，此sugar主要是为了达到精巧的GPath的简洁性。且另一方面，在从js或者是对泛函式编程（fp）有点入门知识的人看来，closure都应该与function划上等号。
应该说，groovy的closure一开始也是如此。唯一是，同样为了GPath的简洁性，采用了可省略return的设计（直接返回最后一个语句的值）。
从此，groovy的codebase中，所有closure几乎都没有return关键字的出现。因为几乎没有必要，所以似乎没有理由记得它甚至提到它。由此，一扇门打开了……
考虑一个传统程序。这个函数检查名为file的文件的每一行，并返回满足filter的第一行行号，否则返回-1。
def findLine(file, filter) {
lineNo = 0
f = new File(file)
while(!f.isEOF()) {
line = f.readLine()
if (filter(line)) return lineNo;
else ++lineNo
}
return -1
}
现在一个newbie刚刚看了几个closure的例子，兴奋异常，于是换用closure style来撰写：
def findLine(file, filter) {
lineNo = 0
new File(file).eachLine { line |
if (filter(line)) return lineNo; else ++lineNo
}
return -1
}
Ok，一切看上去没错，代码更清晰的表达了程序的主旨，几乎没有多余的东西。
但是，不幸的是，这段程序在Classic Groovy里面是无法达到预期效果的，findLine总是返回-1！
因为在eachLine之后的匿名closure中的return是从该closure返回到eachLine方法内部的调用点上（事实上eachLine方法只是简单的忽略这个返回值，没有任何人期待它的到来），而不是如程序员所期望的返回给findLine的调用者！
ok，这是程序员的问题，误用了return——有人会简单的下结论。如何用建议的Closure.BREAK常量标志来达成这个功能先不论，仅仅考虑到这个return是多么直觉的事情，并且groovy的目标就是要让程序员能按直觉办事（去掉烦心的程序终结符;居然还允许跨行，就是例证），就不能简单的把问题归咎于程序员。
照例说，在这个结构里面，return的用意非常清楚，不带偏见的说，任何一个java程序员转向groovy之后几乎都会写出这样的程序。由于 closure大量被用于简化迭代结构（Martin Flower号称他因此在没有closure的语言中是如此怀念closure），对于从c-style转过来的程序员来说，面对最常使用的each，自然把它看作for, while结构的替代物，所以把return视作从findLine返回，而不是从匿名closure返回是狠自然的。
对此问题，Mike Spille的意见是：一切起因于closure实在太像block，程序员忘记了此处实际上是个语法sugar，本质是个method而并不是一个 block，因而诱导了程序员错误的期望该return的返回位置。既然如此，我们就应该明确哪里是block哪里是closure。其建议就是增加一个指示closure的关键字，譬如def { closure code... }
对此，有人尖锐的指出，那还不如去用C#的delegate！（另一方面，那也是js的实际情况，function关键字就相当于此关键字）
无论如何，情况很清楚：普通block和closure在syntax上如此相似以至于无法分辨，解决方案无外乎，区分它们（Mike Spille的建议），或者统一它们——使得break/return等的语义在block和closure中一致！
John Rose提出的并且为多数人接受的方案是，应该令closure的return如程序员最可能期望的那样行为：返回到定义其的函数上。并且他还参照 smalltalk, ruby, lisp等提出了break, continue在closure中的一揽子改进语法和语义。由此，通过在closure中使用continue L:value的语法结构，可以达到从label L处返回value的需求。（当然实际需要使用这样怪异的continue的机会其实很少，按照我一贯的语调——你当然可以用xxx，但是如果需要用到 xxx，那往往是坏味道的信号……）
对此提案，Mike Spille自然是全力反对，对此的指责还牵涉上了开发进度、管理模式等问题。如我没有看错，Mike Spille的rant（虽然他自己不承认）甚至多次要求几个核心人物下台……:D
顺便说一下，在我写前面那个mail的时候，还没有意识到这个问题。John Wilson的re中向我指出了这个棘手问题：
On 16 Jan 2005, at 13:53, Shijun He wrote:
> I think there is no essential difference between closure and block.
> User have a block, then want to reuse the block. make the block can be
> passed or returned or parameterized --- that is closure.
>
this is almost true but not quite..
if (a == 1) {
return // returns from enclosing function
}
a.each {
return // returns from closure
}
this (and break in a closure) catches people out a lot.
This has been discussed a great deal but we have not come up with a
solution which pleases everybody.
显然，要pleases everybody是mission impossible :( 事实上吵的天翻地覆……Mike Spille已经被冠以FUD的名号了。
最近几天，我也跟pt同志讨论了这个问题，并且还拉出了ruby和lisp/scheme来“寻根”。pt同志的意见与Mike Spille出奇的一致。pt坚持认为closure就应该是function，改变return的语义是不可接受的。但是ruby的现状却是更接近 John Rose所说的（至少匿名closure的return不返回closure本身而返回到上层函数）。如果我们不怀疑John Rose的专业水准（这点倒是连Mike Spille也承认的，John是个有多种语言经验的高手），那么closure的这种return语义，是Smalltalk的语言标准规定的，而 ruby有大量的概念是师从smalltalk的，closure应该也不例外。进一步的，连Groovy的主要设计者James Strachan都发话了：我们不是要改变什么，而是要把从来没有明确下来的return/break/continue的语义明确下来，是要把尚未完全实现的closure功能完全化。（我乱说一句：这个有马后炮之嫌:)）。
问题最后进入了“哲学”阶段（请千万不要误会我是在调侃哲学）。那就是“什么是closure”。显然，目前为止我更相信John Rose的说法，lisp以来的closure都是如此，即一种特殊的block结构体。连Mike Spille的许多议论也只是说，groovy的目标是java程序员，应此不必全盘“西化”，应首先考虑java程序员的接受程度，譬如 closure/block的统一会破坏对java程序结构的认识根基。（不过此点在我看了'Java中的closure'这篇奇闻逸事之后，就根本不能说服我了。）
common lisp，具有特殊的操作符就叫做block，还有return-from，可以return到任何指定的层级！可谓是超级彻底的block！！另一方面，pt强烈认为closure就是lambda，或者说是lambda在命令式语言（OO语言？）中的复制品。他还认为跳转到上级lex应该以 call/cc方式实现。俺对lisp/scheme所知甚少，也不可能想清楚这当子事情。不过至少有一点是清楚的：Groovy的选择已经作出，并且我也觉得这是符合其核心价值的。至于其与block, func, method的关系，我尚无力作出论断。先走着瞧吧……
