Haskell的标准库类型类的替代实现 [英] Alternative implementations of Haskell's standard library type classes

问题描述

我见过许多人抱怨标准库中的一些类型类，比如说Monad应该需要Functor，甚至Monad应该要求Applicative，Applicative应该要求指向，Num should not需要显示等，
所以，我有一些问题：

1. 是否有参数树的方式类型依赖关系具有社区所认为的那些缺陷，或者这只是历史上事情的结果？

会破坏现有的代码吗？ 有没有替代实现的基本类型类（特别是箭头，单子，应用等）正确的类依赖关系？除了向后兼容性之外，还有一些（主要是装饰性的，但很单调乏味的） ）



没有向上的隐式定义：处理类问题的原因很简单， Monad 完全由纯粹和（>> =）定义; fmap 和（*）可以用这些术语编写。在适当层次中，每个实例都需要写出来。在这种情况下，这并不算糟糕，但随着粒度的增加，每个添加一些小函数的实例数量也随之增加。如果类定义可以根据它们自己的函数为超类功能提供默认实现，那么它将大大简化事情，因此像（>> =）在超类中的函数可以作为整个相关层次结构的定义。



上下文膨胀：只要有一个原因 Num 需要显示和 Eq ，这是因为打印和比较等号的数字很常见。这些是严格正交的，但将它们分开意味着执行所有三件事的函数现在必须指定它们类型中的所有三个类。这在技术上是一件好事，但同样，随着粒度的增加，功能类型签名也会随之增加。



整体式依赖关系：类型类及其超类的层次结构可以添加到，但不能更改或替换。如果一段代码感觉需要替换它自己的某些常见类型类的版本 - 比如说，使用像这样的东西来替换 Monad - 在这一点上，层次被切断;与使用 Monad 的其他定义的代码的兼容性必须在一定程度上手动提供，并且构建在其他定义之上的任何类型类都必须重新实现或转换，即使依赖于只有这两个定义共享的行为的一个子集。





没有明确正确的层次结构：正如上面所暗示的那样，类的粒度。例如，真的需要存在 Pointed ，或者只需 Applicative 就足够了吗？这里真的没有答案，这是普遍理想的，不应该有。





我怀疑，替换现有类型类型的努力可以通过首先处理上面的问题，在这之后，替换类型类将不那么痛苦，甚至比形式化要少得多。例如，@luqui提到的类型同义词提案将是朝这个方向迈出的重要一步。




I've seen many people complaining about some of the type classes from the standard library saying things like "Monad should require Functor" or even "Monad should require Applicative", "Applicative should require Pointed", "Num shouldn't require Show", etc, So, I have some questions:

1. Are there arguments for the way the tree of type class dependencies have those "flaws" perceived by the community or is this just the result of how things were done historically?

2. How drastically a change in this would break existing code?

3. Are there alternative implementations of the basic type classes (particularly arrows, monads, applicative, etc...) around that implement the "right" set of class dependencies?

解决方案

Beyond backwards compatibility, there are some (mostly cosmetic, but tedious to deal with) issues due to the fairly simple way that Haskell treats type classes:

No upward implicit definition: Monad is fully defined by just pure and (>>=); fmap and (<*>) can be written in terms of those. In a "proper" hierarchy, each instance would need to be written out. It's not too bad in this case but as the granularity increases so do the number of instances that each add some small function. It would simplify things substantially if class definitions could supply default implementations for superclass functions in terms of their own functions, so that functions like (>>=) which fully subsume multiple functions in superclasses can serve as a definition for the entire relevant hierarchy.

Context bloat: Insofar as there's a "reason" that Num requires Show and Eq, it's because printing and comparing equality of numbers is pretty common. These are strictly orthogonal, but separating them means that functions doing all three things now have to specify all three classes in their type. This is technically a good thing but, again, as granularity increases so will function type signatures.

Monolithic dependencies: A hierarchy of type classes and their superclasses can be added to, but not altered or replaced. If a piece of code feels the need to substitute its own version of some common type class--say, using something like this to replace Monad--the hierarchy is cut off at that point; compatibility with code using other definitions of Monad must be provided manually to some degree, and any type classes built on top of the other definition have to be reimplemented or translated even when reliant on only a subset of behavior that both definitions share.

No clearly correct hierarchy: As implied by the above, there are choices to be made in the granularity of the classes. For instance, does Pointed really need to exist, or does just Applicative suffice? There's really no answer here that's universally ideal, and there shouldn't have to be.

I suspect that efforts to replace the existing type classes would be better served by first tackling the above issues, after which replacing the type classes would be far less painful, or even little more than a formality. The type class synonyms proposal that @luqui mentions, for instance, would be a major step in this direction.

这篇关于Haskell的标准库类型类的替代实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！