haskell - 如果恢复容器很困难，“Store”comonad 的意义何在？

Question

一个尖的容器是一个comonad，这个观察可以用来获得一些有用的效果，比如模板卷积，几乎是免费的。此外还注意到，instance Comonad 可以通过Store 共单子 （通过部分应用的索引函数）以标准方式获得 an ，并且它的工作方式与手写定义一样好。

但是这种方式有个缺点：Store本质上是一个函数，一旦把东西做成函数，回去就不舒服了。而且我注意到在某些情况下，需求的微小变化需要完全放弃comonad的概念，并回到最初容器的考虑。我发现它类似于最终的无标签评估：本地转换很容易，但是它们需要的上下文越多，它就越复杂。可以通过在光标空间的相应子集上迭代提取来恢复初始容器的任何部分，但是为什么首先将初始类型换成最终类型呢？

换句话说，有 2 种方式来表示容器，并且都同样有利于 的定义instance Comonad：

1. 作为“初始”数据类型。如果没有依赖类型，Haskell 中的简单定义instance Comonad，当容器与索引配对时，是部分的（索引可能指向容器形状之外的位置），但它仍然可以工作。
2. 作为“最终”部分应用的索引函数。一个容器可以通过将其包裹在Store. 然后它会自动与索引配对。偏颇论点同样适用，因此无法获得安全性。

当初始类型与最终函数进行交换时，为初始类型定义的所有方法都将丢失，直到通过或多或少的精心设计恢复。鉴于对小型有限容器的访问是不安全的（大多数索引未定义），并且容器本身不可查询，因此编程变成了扫雷游戏。我没有有意放入的初始容器的任何属性EnvT，都会丢失。总而言之，无论 Store应该提供什么安全或便利利益，都受到处理容器最终表示的困难的挑战。

更简洁地说，一个尖头容器是一个comonad，但Store只是一个comonad。

那么，动机是Store什么？我们能得到一个instance Comonad，或者至少Extend，更便宜吗？

标签： haskellcomonad