包版本控制策略 - 无害类型更改？

Question

package versioning policy指定更改任何实体的类型会更改 A.B.C 中的 B 号码。

但是，在我看来，某些类型更改不会破坏依赖代码。特别是，请考虑以下示例，其中我删除了Typeable类约束：

- foo :: Typeable a => AddHandler a -> NetworkDescription (Event a)
+ foo :: AddHandler a -> NetworkDescription (Event a)

所以，我的问题是：

  

可以在函数break依赖代码上删除类型类约束吗？在引入此更改时，我应该更改 B 号码或仅更改版本 A.B.C 中的 C 吗？

Answer 1

我已经回复了-cafe，但我也会在这里回答：

你应该碰撞C号。 PVP规则2指定API添加意味着要增加版本的C部分。删除约束的行为类似于添加新函数：之前工作的代码继续工作，但针对新API编写的代码可能不适用于旧API。

因此，如果程序员针对foo的0.1.2版开发代码，他会指定foo >= 0.1.2 && < 0.2作为要求。他不希望他的代码对foo-0.1.1起作用。这适用于删除约束。

Answer 2

  

可以在依赖于函数中断的代码上删除类型类约束吗？

不，我不相信。这是我的推理。将约束视为附加函数参数是很常见的：一个隐式传递的类型类字典。您可以稍微考虑一下，并想象约束是证据的记录，它是隐式传递的。因此，类型Foo可以被认为是{} -> Foo，其中{}表示隐含证据的空记录。 Foo本身是否是一个函数是无关紧要的。

现在，假设我们的API承诺提供类型

的东西

{SomeConstraint} -> Foo

但我们实际提供的是

{} -> Foo

好吧，记录子类型告诉我们

{SomeConstraint} <: {}

因此功能子类型告诉我们

({} -> Foo) <: ({SomeConstraint} -> Foo)

因此，在某个人的程序中，我们找到了一个形状为{SomeConstraint} -> Foo的洞，我们可以插入一个{} -> Foo。换句话说，什么都没有打破。用户向我们提供了SomeConstraint满意的证据，我们只是忽略它。

---

起初我认为类型推断中的奇怪角落案例可能会导致问题，但我想不出任何实际情况的例子。所以这种想法被想象力的耗尽证明是错误的。