Question

当比较Go和Scala结束语句检测时，我发现Scala的规则更丰富，即：

除非满足下列条件之一，否则行结尾将被视为分号   条件是真的：


有问题的行以单词形式结束，作为语句的结尾不合法，例如句号或中缀运算符。

下一行以一个无法启动语句的单词开头。

该行在括号（...）或括号[...]内结束，因为它们无论如何都不能包含多个语句。

引自Scala - The rules of semicolon inference。

规则＃1是Go的工作原理。规则＃3也是。唯一的区别是规则＃2 - 它涉及单一前瞻，因为涉及一个令牌（“单词”）。

涉及什么样的性能损失：1％慢，5％，10％？

我希望看到评论（不是问题）为什么Go设计师会忽略该规则 - 如果不是为了表现，它会使语言更可靠，例如在方法链中：

x = some_object.select(...)
               .sort(...)
               .reverse(...)
               .where(...)
               .single()

如果我没有误认为Go这是一个错误（您可以通过两种可能的方式解决它 - 将括号中的整个语句或括号中的表达式，但它是手动调整），Scala将采用它应该。< / p>

Answer 1

与编译器必须执行的所有其他操作相比，性能损失完全可以忽略不计。 Scala-internals邮件列表在Haoyi Li和Martin Odersky之间进行了以下交换，关于Haoyi为Scala写的一个parboiled2解析器：

Haoyi Li：在perf [ormance]方面，它可以在15秒内解析scala / scala，lift，scalaz，scalajs，playframework和shapeless中的所有 ....有谁知道如何编译器和宏中的大部分时间都花在解析上？我的印象是绝大多数时间都是在类型检测器中度过的。

Odersky：是的，与编译器的其他任务相比，解析非常微不足道......也就是说，[下一代Scala编译器的解析器]（手写，2100行，包括错误报告，准确位置和树建筑）每秒达到数十万行。如此沉闷仍然有一些方法可以击败它： - ）

当我们谈论每秒解析数十万行代码包括规则＃2时，可以推断速度不是问题。 Go编译往往以每秒around 20k lines计时，所以即使Go解析花费零时间，并且Scala解析的整个时间被单行前瞻占用，它也会不到建设过程的罚款的10％。

实际上它应该更像是0％。 Lookahead通常很便宜;你已经有一个令牌流，所以你只需看下一个。

Answer 2

似乎行开头是什么，但语句编译器会抱怨。您也可以在Go https://play.golang.org/p/h8NYnBXjFI

中链接方法

单个令牌前瞻的性能损失是多少？

2 个答案: