Scalaz Bind [Seq]类型类 [英] Scalaz Bind[Seq] typeclass

问题描述

我目前正在将一些代码从传统的Scala移植到Scalaz风格.

I'm currently porting some code from traditional Scala to Scalaz style.

在我的大多数代码中，在暴露的API签名中使用Seq特性是很普遍的，而不是直接使用具体类型(即List，Vector).但是，这给Scalaz带来了一些问题，因为它没有提供Bind [Seq]类型类的实现.

It's fairly common through most of my code to use the Seq trait in my exposed API signatures rather than a concrete type (i.e. List, Vector) directly. However, this poses some problem with Scalaz, since it doesn't provide an implementation of a Bind[Seq] typeclass.

即这将正常工作.

List(1,2,3,4) >>= bindOperation

但这不会

Seq(1,2,3,4) >>= bindOperation

出现错误could not find implicit value for parameter F0: scalaz.Bind[Seq]

我认为这是Scalaz中的一个故意设计决定，但是不确定如何使用最佳实践.

I assume this is an intentional design decision in Scalaz - however am unsure about intended/best practice on how to precede.

我应该适当地直接将我的代码写到List/Vector上，而不是使用更灵活的Seq接口吗?还是应该简单地定义自己的Bind [Seq]类型类?

Should I instead write my code directly to List/Vector as appropriate instead of using the more flexible Seq interface? Or should I simply define my own Bind[Seq] typeclass?

推荐答案

集合库会进行后空翻以适应子类型化:在特定集合类型(列表，地图等)上使用map时，您将(通常)返回相同的类型.它通过使用一个极其复杂的继承层次结构以及诸如CanBuildFrom之类的类型类来管理此问题.它可以完成工作(至少可以说是有争议的)，但是复杂性并不是很原则性的.一团糟.很多人讨厌它.

The collections library does backflips to accommodate subtyping: when you use map on a specific collection type (list, map, etc.), you'll (usually) get the same type back. It manages this through the use of an extremely complex inheritance hierarchy together with type classes like CanBuildFrom. It gets the job done (at least arguably), but the complexity doesn't feel very principled. It's a mess. Lots of people hate it.

作为图书馆用户，通常很容易避免复杂性，但是对于图书馆设计师来说，这是一场噩梦.如果我提供Seq的monad实例，则意味着我所有用户的类型都将其使用monadic操作的每种类型的层次结构提升到Seq.

The complexity is generally pretty easy to avoid as a library user, but for a library designer it's a nightmare. If I provide a monad instance for Seq, that means all of my users' types get bumped up the hierarchy to Seq every type they use a monadic operation.

无论如何，Scalaz的人们还是不太喜欢子类型化，因此Scalaz在大多数情况下都停留在层次结构的叶子(List，Vector等)周围.您可以看到有关此决定的一些讨论

Scalaz folks tend not to like subtyping very much, anyway, so for the most part Scalaz stays around the leaves of the hierarchy—List, Vector, etc. You can see some discussion of this decision on the mailing list, for example.

当我第一次开始使用Scalaz时，我编写了很多实用程序代码，试图为Seq等提供实例，并使它们可用于CanBuildFrom.然后我停了下来，现在我倾向于只在自己的代码中使用List，Vector，Map和Set来遵循Scalaz.如果您致力于"Scalaz风格"，则也应该这样做(甚至采用Scalaz自己的IList，ISet，==>>等).不过，您不会更广泛地就最佳实践找到明确的协议，并且两种方法都可以奏效，因此您只需要尝试找到自己喜欢的方法即可.

When I first started using Scalaz I wrote a lot of utility code that tried to provide instances for Seq, etc. and make them usable with CanBuildFrom. Then I stopped, and now I tend to follow Scalaz in only ever using List, Vector, Map, and Set in my own code. If you're committed to "Scalaz style", you should do that as well (or even adopt Scalaz's own IList, ISet, ==>>, etc.). You're not going to find clear agreement on best practices more generally, though, and both approaches can be made to work, so you'll just need to experiment to find which you prefer.

这篇关于Scalaz Bind [Seq]类型类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！