scala - Scala的动机是否强调形式语言理论和良好的风格？

Question

为什么很多人说在Scala中使用下划线是一种好习惯，并使您的代码更具可读性？他们说，动机来自形式语言理论。但是，许多程序员，特别是来自其他语言的程序员，尤其是具有匿名功能的程序员，更喜欢不要特别针对占位符使用下划线。

那么下划线有什么意义呢？为什么Scala（以及om-nom-nom所指的其他一些功能语言）带有下划线？就复杂性和语言理论而言，为什么使用它通常是好样式，这是什么正式的基础呢？

Answer 1

语言学

Scala中大多数下划线使用的起源和动机是允许人们构造表达式和声明而无需总是给该语言的每个变量（我在谓词微积分中指的是“变量”，而不是在编程中）取一个名称。我们一直在自然语言中使用它，例如，我在本句中的前一个句子中使用“ this”来指代一个概念，而在我使用“ this”来引用该句子时，则对我的意思没有任何混淆。在自然语言中，这些词通常被称为“代词”，“照应”，“类比”，指称对象“先行者”或“后继者”，并且理解/取消引用它们的过程被称为“指称”。

算法信息论

如果我们必须先用自然语言命名每个“事物”，然后才能对其进行引用，就象量化谓词和大多数编程语言一样，为了对它进行量化，也要对每种事物进行类似的命名，那么话语就会变得冗长。由于上下文的关系，我们可以推断出“ this”，“ it”，“ that”等单词的含义，因此我们可以轻松做到。

因此，为什么要限制这种简单，优雅和有效的方式来与自然语言进行交流呢？因此，它已添加到Scala。

如果我们确实尝试为每个“事物”或“事物类型”命名，那么句子将变得冗长而复杂，以至于由于其冗长和引入多余符号而变得很难理解。在句子中添加的符号越多，越难理解，因此，这不仅是自然语言，而且也是Scala的良好实践。实际上，可以用Kolmogorov复杂度形式化此断言，并证明采用占位符的句子序列的复杂度要比那些不必要地命名所有事物的句子低（除非在每种情况下名称都完全相同，但这通常没有意义） ）。因此，我们可以得出结论，与某些程序员的看法相反，占位符语法更简单易读。

它在使用中存在一些阻力的原因是，如果一个人已经是一名程序员，则必须努力重新训练大脑，不要给所有东西起名字，就像（如果他们能记住的话）他们可能已经学会了使用MFC编写代码一样。第一名需要付出很大的努力。

例子

现在让我们更正式地看一些特定的用途：

占位符语法

意思是“它”，“它们”，“那个”，“它们的”等（即代词），例如1个

lines.map(_.length)

可以读为“将线映射到其长度”，类似地，我们可以将 lineOption.map(_.length)读为“将线映射到其长度”。就复杂性理论而言，这比“对于行中的每个'行'，取'line'的长度”更简单-这将是 lines.map(line => line.length)。

当与类型注释一起使用时，也可以读作“ the”（定冠词），例如

(_: Int) + 1

“将1加到整数”

存在类型

意思是“某种类型”（代词“ some”），例如

foo: Option[_]

表示“ foo是某种类型的选项”。

更高种类的参数

同样，基本上是指“某种类型”（代词“ some”），例如

class A[K[_],T](a: K[T])

可以读为“ A类需要某种类型的K ...”

模式匹配通配符

意思是“任何”或“任何”（代词），例如

case Foo(_) => "hello"

可以理解为“对于包含任何内容的Foo，返回'hello'”，或“对于包含任何内容的Foo，返回'hello'”

导入通配符

意思是“一切”（代词），例如

import foo._

可以理解为“从foo导入所有内容”。

默认值

现在，我将其读为“ a”（不定冠词），例如

val wine: RedWine = _

“给我红酒”，服务员应该给你房子红葡萄酒。

下划线的其他用途

下划线的其他用途与本问答的重点无关，尽管如此，我们还是简单地讨论它们。

忽略的值/参数/提取

让我们以一种明确的“模式安全”方式忽略事物。例如。

val (x, _) = getMyPoint

说，我们将不使用第二个坐标，因此当您在代码中找不到用处时，无需变得怪异。

导入隐藏

只是说“除外”（介词）的一种方式。

功能应用

例如。

val f: String => Unit = println _

这很有趣，因为它在语言学上有一个精确的类比，即名词化，即“使用动词，形容词或副词作为名词短语的头，无论是否经过形态转换”-维基百科。更简单地说，这是将动词或形容词变成名词的过程。

在特殊方法名称中使用

纯粹是语法问题，与语言学无关。