Groovy在EOS问题上的痛苦权衡
看了点groovy的ml archives，争论不休的EOS/EOL问题。
C-style的语言本没有EOS问题，语法规定显式的';'作为EOS。但是从JavaScript这个异类开始，使用了Automatic Semicolon Insertion的方式，使得在许多情况下，';'是可省略的。
以前就看到有人诟病这种设计，现在才突然发现，其产生含混的根源是：其他不用';'的语言多以EOL作为天然的EOS，但是这种可省略';'的设计导致缺乏确定的EOS，有时候EOL是EOS，有时候又不是！依赖上下文的判断在某些情况下并不是很直观。
这种情况在Groovy更严重。
Groovy有更抽象的设计原则叫做PHIM: "Parse how I mean"。以这种思想为指引，产生许多有趣同时又是危险的特性，例如可以省略return关键字。
更自由的语法似乎不可避免带来更多歧义性，PHIM往往产生含混和冲突。权衡的结果是需要一些更严格的限制，例如有人建议是只有Method/Closure最后一行才能省略return关键字。
现在根据符合直觉和简洁的目标，在ml的threads中，参与者不断的提出和改进针对EOS问题的建议，我觉得比较能接受的意见是：非平衡的括号、运算符（以及承袭java的少数keyword结构如if(...)、for(...)、else等）后的EOL不作为EOS。付出的代价是和Java/C等在如下语句意义上的不一致：
a = 1
+ 2
+ 3;
同时，与JavaScript也不一致：
a = f
(param)
类似的问题还有一些。比如最搞笑的一个comment问题：
a = 1 // comment
b = 2 // comment
+ 1 // comment
c = 3 /* comment
comment */ + 1
显然在/*comment*/中，任何comment都被忽略，包括EOL。而在//comment语法中，按照java的规定最后的EOL也是comment的一部分被忽略，这没问题，因为Java中EOS=';'。但是缺乏明确EOS的groovy是不能忽略EOL的，否则就会有奇怪的事情发生（第1、2行结果变成了 a=1b=2）。当然这主要是grammar上的issue，而不是实践上的issue。
可以预见，EOS问题今后还会被不断老调重弹，典型的句型是：“假如去掉optional semcolon的特性，这个语法上的issue就很容易解决……”
然而，尽管有很多证据显示省略';'可能带来了大量麻烦，但是John Wilson的话还是蛮有道理的：
No expert programmers *hate* the situation in which the compiler throws out the program because of a missing semicolon. They ask the very reasonable question "if the compiler knows there should be a semicolon there why the **** doesn't it put it in?"
因此我总体上还是赞同这个特性的。
