Groovy在EOS问题上的痛苦权衡

时间:2021-06-19 19:58:29

看了点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?"

因此我总体上还是赞同这个特性的。