对“替代"类型类的含义及其与其他类型类的关系感到困惑 [英] Confused by the meaning of the 'Alternative' type class and its relationship to other type classes

查看:22
本文介绍了对“替代"类型类的含义及其与其他类型类的关系感到困惑的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在阅读 Typeclassopedia 来学习类型类.我一直无法理解 Alternative(以及 MonadPlus,就此而言).

I've been going through the Typeclassopedia to learn the type classes. I'm stuck understanding Alternative (and MonadPlus, for that matter).

我遇到的问题:

  • 'pedia 说Alternative 类型类适用于同样具有幺半群结构的 Applicative 函子."我不明白——Alternative 是不是意味着与 Monoid 完全不同的东西?即,我将 Alternative 类型类的要点理解为在两件事之间进行选择,而我将 Monoids 理解为关于组合事物.

  • the 'pedia says that "the Alternative type class is for Applicative functors which also have a monoid structure." I don't get this -- doesn't Alternative mean something totally different from Monoid? i.e. I understood the point of the Alternative type class as picking between two things, whereas I understood Monoids as being about combining things.

为什么 Alternative 需要 empty 方法/成员?我可能是错的,但它似乎根本没有被使用......至少在 代码 我能找到.而且这似乎不符合课程的主题——如果我有两件事,需要选择一项,我需要一个空"做什么?

why does Alternative need an empty method/member? I may be wrong, but it seems to not be used at all ... at least in the code I could find. And it seems not to fit with the theme of the class -- if I have two things, and need to pick one, what do I need an 'empty' for?

为什么Alternative类型类需要Applicative约束,为什么需要一种* ->*?为什么不只有 <|>:: a ->->一个?所有实例仍然可以以相同的方式实现......我认为(不确定).它提供了 Monoid 没有提供的什么价值?

why does the Alternative type class need an Applicative constraint, and why does it need a kind of * -> *? Why not just have <|> :: a -> a -> a? All of the instances could still be implemented in the same way ... I think (not sure). What value does it provide that Monoid doesn't?

MonadPlus 类型类的重点是什么?我不能通过同时使用 MonadAlternative 来释放它的所有优点吗?为什么不直接放弃?(我确定我错了,但我没有任何反例)

what's the point of the MonadPlus type class? Can't I unlock all of its goodness by just using something as both a Monad and Alternative? Why not just ditch it? (I'm sure I'm wrong, but I don't have any counterexamples)

希望所有这些问题都是连贯的......!

Hopefully all those questions are coherent ... !

赏金更新:@Antal 的回答是一个很好的开始,但 Q3 仍然开放:Alternative 提供了什么 Monoid 没有提供?我发现这个答案并不令人满意,因为它缺乏具体的例子和具体的讨论 Alternative 的高级性如何将其与 Monoid 区分开来.

Bounty update: @Antal's answer is a great start, but Q3 is still open: what does Alternative provide that Monoid doesn't? I find this answer unsatisfactory since it lacks concrete examples, and a specific discussion of how the higher-kindedness of Alternative distinguishes it from Monoid.

如果要将 applicative 的效果与 Monoid 的行为相结合,为什么不这样做:

If it's to combine applicative's effects with Monoid's behavior, why not just:

liftA2 mappend

这让我更加困惑,因为许多 Monoid 实例与 Alternative 实例完全相同.

This is even more confusing for me because many Monoid instances are exactly the same as the Alternative instances.

这就是为什么我要寻找具体示例来说明为什么需要替代方案,以及它与 Monoid 有何不同 - 或意味着不同的东西.

That's why I'm looking for specific examples that show why Alternative is necessary, and how it's different -- or means something different -- from Monoid.

推荐答案

我不会涵盖 MonadPlus,因为对其法律存在分歧.

I won't cover MonadPlus because there is disagreement about its laws.

在尝试并未能找到任何有意义的示例后,其中 Applicative 的结构自然地导致了与其 Monoid 实例不一致的 Alternative 实例*,我终于想出了这个:

After trying and failing to find any meaningful examples in which the structure of an Applicative leads naturally to an Alternative instance that disagrees with its Monoid instance*, I finally came up with this:

Alternative 的法则比 Monoid 的法则更严格,因为结果不能依赖于内部类型.这将大量 Monoid 实例排除在替代品之外.这些数据类型允许部分(意味着它们仅适用于某些内部类型)Monoid 实例,这些实例被 * -> 的额外结构"所禁止.* 种类.示例:

Alternative's laws are more strict than Monoid's, because the result cannot depend on the inner type. This excludes a large number of Monoid instances from being Alternatives. These datatypes allow partial (meaning that they only work for some inner types) Monoid instances which are forbidden by the extra 'structure' of the * -> * kind. Examples:

  • Monoid 的标准 Maybe 实例假设内部类型是 Monoid => 不是 Alternative

  • the standard Maybe instance for Monoid assumes that the inner type is Monoid => not an Alternative

ZipList、元组和函数都可以成为 Monoid,如果它们的内部类型是 Monoid => 不是 Alternatives

ZipLists, tuples, and functions can all be made Monoids, if their inner types are Monoids => not Alternatives

至少有一个元素的序列 -- 不能是 Alternatives,因为没有 empty:

sequences that have at least one element -- cannot be Alternatives because there's no empty:

data Seq a
    = End a
    | Cons a (Seq a)
  deriving (Show, Eq, Ord)

另一方面,某些数据类型不能被替换,因为它们是 * 类型的:

On the other hand, some data types cannot be made Alternatives because they're *-kinded:

  • 单元 -- ()
  • 订购
  • 数字、布尔值

我推断的结论:对于同时具有 Alternative 和 Monoid 实例的类型,这些实例的目的是相同的.另见 这个答案.

My inferred conclusion: for types that have both an Alternative and a Monoid instance, the instances are intended to be the same. See also this answer.

排除Maybe,我认为这不算数,因为它的标准实例不应该要求Monoid作为内部类型,在这种情况下它将与Alternative相同

这篇关于对“替代"类型类的含义及其与其他类型类的关系感到困惑的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆