scala - 为什么我们需要 "Algebraic Data Types"？

Question

我读过一些关于代数数据类型的解释:

The Algebra of Algebraic Data types I

The Algebra of Algebraic Data types II

The Algebra of Algebraic Data types III

The Algebra of Data, and Calculus of Mutation

这些文章给出了非常详细的描述和代码示例。

起初我以为代数数据类型只是为了轻松定义一些类型，我们可以用模式匹配来匹配它们。但是看了这些文章，我发现里面根本没有提到“模式匹配”，内容看起来很有趣，但比我想象的要复杂得多。

所以我有一些问题(这些文章没有回答):

为什么我们需要它，比如说，在 Haskell 或 Scala 中？

有了它我们能做什么，没有它我们不能做什么？

Answer 1

我们应该从 Haskell wiki 文章 Algebraic Data Types 开始。

在这里，很快，只是我的愿景:

我们需要它们以旧的面向对象方式(或实际上以旧的基于类别的方式)对业务逻辑进行建模，并使其更加类型安全，因为编译器可以检查您是否匹配了所有可能的选择。或者，换句话说，你的函数是 total ，不偏。最终，它使编译器能够证明代码的正确性(这就是推荐使用密封特征的原因)。因此，您拥有的不同类型越多越好 - 顺便说一句，泛型编程可以帮助您生成更多类型。

标准特性:我们可以将类型表示为对象的“集合”，我们可以将对象与类型匹配(使用模式匹配)，甚至可以使用匹配器解构(分析)它。我们还可以使用类型类为此类类型动态添加行为(在编译时)。常规类也是可能的，但在这里它使我们能够将代数模型(类型)与行为(函数)分开

我们可以将类型构造为 products/coproducts不同的对象/类型。您可以将代数类型系统视为一个集合(或更一般地 - 作为一个笛卡尔封闭类别)。 type Boolean = True | False表示 bool 值是 True 的并集(联积)和 False . Cat(height: Height, weight: Weight)是 Height 的“元组”(更一般地 - 乘积)和 Weight . Product (more-less) 表示来自 OOP 的“部分”关系，coproduct - “is”(但以相反的方式)。

它还为我们提供了一种在运行时以多方法样式调度行为的方法(就像在 CLOS 中一样):

  sealed trait Animal
  case class Cat extends Animal
  case class Dog extends Animal

 def move(c: Animal) = c match {
   case Cat(...) => ...
   case Dog(...) =>
   case a: Animal => ...//if you need default implementation
 }

类 haskell :

 data Animal = Dog | Cat //coproduct

 let move Dog d = ...
 let move Cat c = ...

代替:

trait Animal {
  ...
  def move = ...
}

class Cat(val ...) extends Animal {
  override def move = ...
}

class Dog(val ...) extends Animal {
  override def move = ...
}

附言从理论上讲，如果您以代数方式对世界进行建模并且您的函数是完全且纯的 - 您可以证明您的应用程序是正确的。如果它编译 - 它可以工作:)。

P.S.2。我还应该提到 Scala 的类型层次结构，它有 Any因为它破坏了 GADT 定义的良好结构，所以它对类型安全不太好(但对与 Java 和 IO 的互操作有好处)。不止于此 case class可能同时是 GADT(代数)和 ADT(抽象)，这也减少了保证。