为什么Alternative类型类需要成为Control.Applicative子类？

Question

15

Haskell提供了一个标准的类型类“Alternative”，它为任何也是一个Applicative类型的类型提供了有效的<|>运算符。

据我所知，“Alternative”在Applicative上被认为是一个Monoid，然而在很多不是Applicative Functor的类型中，“<|>”操作符似乎也完全合理，并且它不需要任何特定于Applicative类型类的依赖才能正常工作。

“Alternative”是否需要成为Applicative的子类有原因吗？如果是这样，是否有标准的类型类来定义非Applicative类型的类似功能？

- James Davies

2

“Monoid” 将是非应用类型的类。 - Lee

4

@Lee，这并不完全符合类型检查，因为Monoid是一类类型，而Alternative是一类类型构造器。希望我们可以在类型构造器上进行局部量化约束，例如(forall a. Monoid f a)，但这是不允许的。 - pigworker

从技术上讲，Alternative只是“Applicatives的幺半群”，因此“Monoid”似乎是更常见的情况。据我所知，<|>运算符的预期用法是“选择或另一个”，这与mconcat有些不同。 - James Davies

2

在我看来，所有的范畴论类型类都有点纠缠在一起，主要是由于历史原因（即向后兼容性）。我认为这很相关：https://dev59.com/kWkw5IYBdhLWcg3wDWTL - MathematicalOrchid

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，

- Sjoerd Visscher · Accepted Answer

6

- Sjoerd Visscher

如果Alt是Alternative的超类，Apply是Applicative的超类，那不是更好吗？ - imz -- Ivan Zakharyaschev

我似乎错过了一个可以使用这个 Alt 作为 Semigroup 的实例。(类似于 Alt newtype 可以将 Alternative 用作 Monoid 的方式。) - imz -- Ivan Zakharyaschev

1

遗憾的是，作为一个半群，它没有 altEmpty :: f a。 - Tom Ellis