用户定义的基于元组的数据构造函数

问题描述

我试图再次理解The Little MLer。 TLMLer有这个SML代码

datatype a pizza = Bottom | Topping of (a * (a pizza))
datatype fish = Anchovy | Lox | Tuna

我已经翻译成

data PizzaSh a = CrustSh | ToppingSh a (PizzaSh a)
data FishPSh = AnchovyPSh | LoxPSh | TunaPSh

然后可能是更接近 TLMLer 的替代方案

data PizzaSh2 a = CrustSh2 | ToppingSh2 (a,PizzaSh2 a)

然后我从每个披萨中制作一个披萨

fpizza1 = ToppingSh AnchovyPSh (ToppingSh TunaPSh (ToppingSh LoxPSh CrustSh))
fpizza2 = ToppingSh2 (AnchovyPSh,ToppingSh2 (LoxPSh,ToppingSh2 (TunaPSh,CrustSh2)))

分别是 PizzaSh FishPSh 和 PizzaSh2 FishPSh 类型。

但第二个版本（可以说更接近原始 ML 版本）似乎“另类”。就好像我正在创建一个 2 元组，当我在第二个成员递归扩展的地方“反对”浇头时。我可以假设 PizzaSh2 的参数化数据构造函数“函数”实际上并没有构建元组，它只是借用元组作为缺点策略，对吗？在 Haskell 中，PizzaSh 或 PizzaSh2 哪个更可取？据我了解，元组（笛卡尔积）数据类型将具有单个构造函数，例如 data Point a b = Pt a b，而不是 ored-together (|) 构造函数的不相交联合。在 SML 中，“*”表示产品，即元组，但同样，这只是一个“类似元组的东西”，即它只是一种将比萨饼组合在一起的元组方式？

解决方法

在 Haskell 中，我们更喜欢这种风格：

data PizzaSh a = CrustSh | ToppingSh a (PizzaSh a)

Haskell 中不需要在那里使用元组，因为像 ToppingSh 这样的数据构造函数可以接受多个参数。

使用额外的对

data PizzaSh2 a = CrustSh2 | ToppingSh2 (a,PizzaSh2 a)

创建的类型几乎与前一个同构，但处理起来更麻烦，因为它需要使用更多的括号。例如

foo (ToppingSh x y)
-- vs
foo (ToppingSh2 (x,y))

bar :: PizzaSh a -> ...
bar (ToppingSh x y) = ....
-- vs
bar (ToppingSh2 (x,y)) = ...

此外，该类型确实只是几乎同构的。当使用额外的一对时，由于懒惰，我们还有一个可以用类型表示的值：我们有一个对应

ToppingSh x y     <->    ToppingSh2 (x,y)

在这种情况下崩溃

???               <->    ToppingSh2 undefined

也就是说，ToppinggSh2 可以应用于非终止（或其他异常）、成对值表达式，并构造一个无法使用 ToppingSh 表示的值。

在操作上，为了实现 GHC 使用双重间接（大致是指针到指针，或 thunk-returning-pair-of-thunk），这进一步减慢了代码的速度。因此，从性能的角度来看，这也是一个糟糕的选择，如果有人关心这种微优化。

,

就 Haskell 方面而言，它绝对是在 (,) 构造函数中嵌套了一个 ToppingSh 构造函数。不执行您请求的嵌套将违反 Haskell 的非严格语义。如果删除嵌套，您将无法区分 undefined :: PizzaSh2 () 和 ToppingSh undefined :: PizzaSh2 ()。是的，大多数时候，这不是您想要的。 PizzaSh 是 Haskell 中更自然的表述，除非您有特殊需要能够在评估过程中引入另一个底部。

我无法解决任何特定机器学习实现的幕后情况。虽然我可以说使用严格的评估语义，但没有观察到行为差异，这意味着编译器可以自由使用更广泛的方法。