为什么在CloudHaskell中仍然使用远程表和StaticLabel？

Question

我正在阅读distributed-process及相关软件包的源代码。 在distributed-static中，我们定义了StaticLabel：

data StaticLabel =
    StaticLabel String
  | StaticApply !StaticLabel !StaticLabel
  | StaticPtr SDynamic
  deriving (Eq, Ord, Typeable, Show)

然后用于将Static定义为newtype包装器 StaticLabel附加了一个用于类型安全的幻像变量：

newtype Static a = Static StaticLabel
  deriving (Eq, Ord, Typeable, Show)

我对StaticApply没有任何疑问，它只是将两个静态混为一谈 值。但是，StaticLabel和StaticPtr似乎达到了同一目标 以不同的方式。

如果我们选择StaticLabel，我们只需要/转发一个String标签 然后可以用来查找Dynamic的{​​{1}}值：

RemoteTable

newtype RemoteTable = RemoteTable (Map String Dynamic) 的位置（在Dynamic中定义）：

rank1dynamic

与data Dynamic = Dynamic TypeRep GHC.Any 中包含的SDynamic几乎相同：

StaticPtr

不同之处在于，data SDynamic = SDynamic TypeRep (StaticPtr GHC.Any) 我们Dynamic没有间接， 使用GHC.Any我们必须查找该值。结果是一样的：我们收到了 如果目标SDynamic是Any我们可以unsafeCoerce。{ instanceOf 我们存储在TypeRep或TypeRep中的SDynamic。

远程表的管理虽然在某种程度上通过TH自动化，但是 仍然有点烦人，为什么不只使用Dynamic s？ StaticPtr StaticLabel 存在只是为了与旧的GHC向后兼容或我错过了 什么？

Answer 1

这样做的一个主要原因是我们必须具有向后兼容性并支持3个主要版本的GHC。如果我们想立即跳入静态指针解决方案，那也是不明显的。例如他们的“稳定性”较弱。基本上唯一的保证是，对于相同版本的编译器，库和相同的源代码 - 静态指针将被编译为相同的值。实际上，分布式流程的定义考虑到了这一点，但有些人希望拥有更稳定的指针和静态标签，因为您可以为标签定义自己的规则，并且在不同的可执行文件中具有相同的标签。

如果对静态指针的保证足够了，那么就会有distributed-closure包，它提供了一个基于静态指针的函数引用。使用这个包你根本不需要使用remotetable，只留下分布式进程的内部和后向兼容性。