haskell - 有什么证据表明 Clojure Zippers 会因表达为 comonad 而受益？

Question

在 this presentation [2005] 我们在幻灯片 32 中读到:

The zipper datatype hides a comonad. This is exactly the comonad one needs to structure attribute evaluation.

看来你可以表达Zippers in terms of Comonads 。这甚至看起来possible in Scala 。

查看zipper source ，我们看到以 Clojure 元数据表示的 zipper 。

我的问题是，有什么证据表明 Clojure Zippers 会因表达为 comonad 而受益？

Eric suggests好处是

so we need to get all the possible zippers over the original group!

Answer 1

您的要求存在一些结构性谬误。 zipper 不能被表达为Comonad，而是它们本质上。

同样，整数就是幺半群(以两种方式!)，无论您是否选择接受这个事实。

因此，您不应该问有什么好处，而应该问“我可以通过识别共生结构来提高清晰度吗？”

答案是“是的!”

<小时/>

共元结构意味着任何 zipper 上都存在两种有趣的方法。第一个是明显且明显有用的——“这里”功能。为了使这一点更加具体，我将制作一个列表 zipper

data Zipper a = Zipper { before :: [a], here :: a, after :: [a] }

现在 here::Zipper a -> a 是通常称为 extract 的共元函数。

extract = here

因此，可以公平地说，每次您检查 zipper 指向的物体时，您都在使用共元接口(interface)。

也就是说，extract 是界面中无聊的一面。更有趣的是extend。

extend :: (Zipper a -> b) -> Zipper a -> Zipper b

extend 捕捉到的是对 zipper 中的每个元素应用“上下文化转换”的想法。 Comonadic 结构指出，有一个标准且结构良好的方法可以通过将转换“扩展”到整个 comonad 来实现此目的。

这样的示例可能是将卷积应用于列表 - 例如，一个小的模糊函数:

blurKernel :: Fractional a => Zipper a -> a
blurKernel (Zipper prior current future) =
  (a + current + c) / 3
  where
    a = case prior of
      [] -> 0
      (p:ps) -> p
    c = case future of
      [] -> 0
      (p:ps) -> p

blur :: Fractional a => Zipper a -> Zipper a
blur = extend blurKernel

那么为什么要用这些术语来写blur呢？难道没有一种自然的、递归的或迭代的公式可以同样工作并且更明显吗？

好吧，通过认识到blur是基于comonadic扩展，我们已经在Zippers操作中暴露了通用结构。这有利于保持 DRY。

我们也开始认识到 zipper 的一些深刻的东西——每个 zipper 都有共同的扩展，所以也许我们可以将模糊推广到分数的所有 zipper code> 类型，通过某种方式仅泛化 blurKernel 并在我们关心的每个 Zipper 中扩展它。

<小时/>

无论如何，我希望我的例子表明，无论你是否注意到， zipper 都是共同的。

良好的 Haskell 抽象通常就是这种情况——它们是某些类型的代码运行方式的自然属性。为了方便起见，类型类只是捕获它们。 也许/State/List/etc 会是 monad，即使它们不是 Monad。 Zipper/Store/Trace 也将是 comonad，即使它们不是 Comonad。