为什么命令式语言没有模式匹配？

Question

所以，函数语言中的模式匹配是非常棒的。我想知道为什么大多数命令式语言没有实现这个特性？据我所知，Scala是唯一具有模式匹配的“主流”命令式语言。机箱/开关结构的威力要小得多。

特别是，我感兴趣的是缺乏模式匹配是由于技术原因还是历史原因？

Answer 1

大部分都是历史性的。模式匹配--更重要的是，代数数据类型--是在1980年为函数语言希望而发明的。从那以后，它很快就变成了ML，后来被其他功能语言所采用，比如Miranda和Haskell。主流的命令式世界通常需要几十年的时间才能获得新的编程语言思想。

其中一个特别阻碍采纳的原因是，主流一直被面向对象的意识形态所主导。在那个世界里，任何不被对象和子类型表达的东西都被认为是道德上的“错误”。可以说，代数数据类型是与之相反的。

也许也有一些技术原因使其在功能语言中更加自然：

• 常规的范围规则和变量的细粒度绑定构造是函数式语言中的规范，但在主流命令式语言中不那么常见。
• 尤其是因为模式绑定不可变变量。
• 类型检查模式匹配依赖于功能类型系统更好的结构和刚性，以及它们与计算逻辑的紧密联系。主流类型系统通常远离这一点。
• 代数数据类型需要堆分配(除非您想浪费大量空间并禁止递归)，如果没有垃圾收集，将非常不方便。然而，主流语言中的GCs通常是针对重量级对象(而不是轻量级功能数据)进行优化的。

Answer 2

直到最近(更准确地说:直到Scala)，人们一直认为模式匹配与表示无知(即OO的定义特性)不相容。由于面向对象( OO )是主流语言中的一个主要范例，在主流语言中拥有一个看似不可调和的特性似乎没有意义。

在Scala中，模式匹配与OO相协调，只需让匹配操作be方法调用对象即可。(事后看来很简单，不是吗？)特别是，匹配是通过调用提取器对象的方法来执行的，与任何其他对象一样，提取器对象只能访问被检查对象的公共API，因此不会破坏封装。

在Scala的启发下，模式匹配库被添加到Newspeak中，其中模式本身是一流的对象(受F#的活动模式的启发)，这是一种非常动态的语言，非常重视OO。(Newspeak甚至没有变量，只有方法。)

请注意，正则表达式是模式匹配的有限形式的示例。多态方法分派也可以看作是模式匹配的有限形式(没有提取特性)的一个例子。实际上，方法分派功能足够强大，可以实现完整的模式匹配，Scala，特别是Newspeak (在后者中，模式匹配甚至被实现为一个库，完全独立于语言)。

Answer 3

这是我的两分钱。使用一个简单的Option模式匹配：

val o = Some(1)

o match {
  case Some(i) => i + 1
  case None => 0
}

在Scala中发生了很多事情。编译器检查是否有完全匹配，为case语句的作用域创建一个新变量case，当然首先从Option提取值。

在Java等语言中，提取值是可行的。实现一些商定的接口的unapply方法，您就完成了。现在，您可以将值返回给调用方。

将提取的值提供给调用者，这在本质上需要闭包，在没有闭包支持的情况下，用常规的OO语言这样做并不太方便。在Java7中，它可能会变得很难看，在那里您可能会使用观察者模式。

如果您在组合中添加了Scala的其他模式匹配功能，比如对特定类型的匹配，例如case i: Int =>；在需要时使用默认子句_ (编译器必须以某种方式检查是否使用_ )；其他检查，如case i if i > 0 =>；等等，从客户端使用它很快就变得非常丑陋(想想Java)。

如果您删除所有这些花哨的模式匹配特性，您的模式匹配将基本上与Java的switch语句级别相匹配。

看起来，即使可能的话，使用匿名类而不支持lambda和强类型系统也是不值得的。