如果 `zip` 是合法类型类的方法，那么是哪一个呢？

Question

为什么会问这个问题 有人可能会说zip 是Applicative 的一种方法，通常的实例是ZipList。我对此不满意，因为它不安全。我也对Align 不满意，因为它包罗万象，过于复杂，而且对于一般情况来说不够具体。

合法类：Haskell 中的某些类型类可能被称为合法。这意味着它们带有必须遵守的平等——一个阶级的法律。这些规律通常来自编程的一个方面的范畴论概念化。例如，Monad 是计算 （无论是什么意思）通过同名的范畴理论设备的概念化。

重叠事物 想要对成箱的事物进行的通常操作是将它们放在彼此之上，如果它们是幺半群，它们就会融合。

例子：

• Arithmetics with Maybe.
• Addition of matrices.

没有足够的规律 这个概念的概念化是通过幺半群函子和相应的Applicative 类型类。然而，有一个烦人的复杂情况，因为通常有两种方法来定义Applicative，这两种方法看起来都很合适。为什么这样？我建议答案是“法律不够”。

例子：

• 算术：

  • Sum monoid 是实际的“endo-monoid”。它只对亲属事物是合法的。例如，您无法将质量和力相加。
  • Product 幺半群将维数 a 和 b 转换为维数 c。增加质量和力量是合法的，可以让我们感到温暖。

  因此，可以从类型推断出正确的幺半群选择。

• 对于列表：

  • 通常的列表direct sum 是更安全的列表。它可以简单地处理任何有限数量的元素，并且可以使用 “对角过程” 定义（例如 LogicT）处理其余有限数量。
  • ZipList 定义显然不安全。它被定义为，给定两个不同长度的列表，将较长的列表裁剪为较短的列表。
  • 长度索引向量是允许安全定义zip 的设备，它要求证明给定列表的长度相同。

• 对于矩阵：

  • 通常的矩阵相加具有维度同质性的（非常合理）要求，与上面提到的长度索引向量相同。由于矩阵习惯性地用于各种现实世界的模拟，例如 3D 图形，一旦矩阵开始被裁剪或填充零，人们会立即抱怨，因此不会出现上述 ZipList 的 ZipMatrix 定义有吸引力。
  • 陌生人Kronecker multiplication 让人联想到列表的直接产物。它也承认Monad的定义。

两种情况 从这些例子中可以看出，我们称之为“monoid”或“monoidal”的事物中混杂了两种不同的想法functor"，而这种区别对于编程来说非常很重要（可能不像纯理论），因为它可以消除混乱，消除不安全因素，主要是，因为在每种情况下，要运行两个完全不相关的算法。

---

我在想，也许单曲面函子的可逆性（也称为“强度”）很重要。但是对 Peano 自然数的 Sum 和 Product 单曲面运算的结果是无法区分的。 （我不确定它们是否可以被认为是幺半群内函数。） 所以，我转而猜测类型的变化是标志。物理量的乘法不会像 Monoid 那样进行类型检查，甚至！

P.S. 有一个 Monad 的实例，用于笛卡尔积上的长度索引向量和 Kronecker 乘法上的矩阵，其中某种 fold zip 为 join。

Answer 1

精确的压缩（正如safe 包所称）可以通过the Representable class 表示。有很多与Representable 相关的理论。就我们目前的目的而言，我们可以专注于...

如果tabulate 和index 与(->) x 同构，则Functor f 是Representable。

...和：

Haskell 类型类别上的可表示内函子与 reader monad 同构，因此可以免费继承大量属性。

由于Representable 函子与某种类型的函数同构（例如，同构对与Bool -> a 同构，无限流与Nat -> a 同构），因此可以通过逐点压缩函数来实现精确压缩。这就是mzipRep（MonadZip 的mzip 的默认实现）所做的：

mzipRep :: Representable f => f a -> f b -> f (a, b)
mzipRep as bs = tabulate (index as &&& index bs)

虽然 MonadZip is a rather awkward class（它主要是实现 MonadComprehensions 扩展的一部分），但它有一个相关的法律，我将用非单子的术语重申它：

信息保存：if () <$ u = () <$ v then munzip (mzip u v) = (u, v)

换句话说，如果u 和v 具有相同的形状，那么mzip 不会丢弃信息（因此它可以被munzip 撤消）。由于Representable 暗示只有一种可能的形状，它允许我们放弃条件，从而获得精确的拉链。

---

切线注释：

ZipList 定义显然是不安全的。它被定义为，给定两个不同长度的列表，将较长的列表裁剪为较短的列表。

我会说这取决于您要使用压缩的目的。有时你会想要或需要精确的压缩，有时你不会（例如，考虑使用zip [0..] 将索引附加到列表的常见技巧）；有时填充而不是修剪是有意义的（参见leftaroundabout's comment）。这就是为什么我更喜欢将精确压缩称为“精确”，而不是“安全”。

然而，有一个令人讨厌的复杂情况，因为通常有两种方法来定义Applicative，这两种方法看起来都很合适。为什么这样？我建议答案是“法律不够”。

我非常不同意如果一个类允许某个数据类型有多个实例，则该类未指定。我宁愿这样说，例如具有笛卡尔积应用程序的列表和具有压缩应用程序的列表是不同的结构，其特征在于相关的态射——碰巧它们可以通过相同的数据类型在 Haskell 中表示。