| layout | title | section |
|---|---|---|
default |
FAQ |
faq |
- What imports do I need?
- Why can't the compiler find implicit instances for Future?
- How can I turn my List of
<something>into a<something>of a list? - What does
@typeclassmean? - What do types like
?andλmean? - What does
macro Opsdo? What iscats.macros.Ops? - How can I help?
The easiest approach to cats imports is to import everything that's commonly needed:
import cats._
import cats.data._
import cats.implicits._
This should be all that you need, but if you'd like to learn more about the details of imports than you can check out the import guide.
If you have already followed the imports advice but are still getting error messages like could not find implicit value for parameter e: cats.Monad[scala.concurrent.Future] or value |+| is not a member of scala.concurrent.Future[Int], then make sure that you have an implicit scala.concurrent.ExecutionContext in scope. The easiest way to do this is to import scala.concurrent.ExecutionContext.Implicits.global, but note that you may want to use a different execution context for your production application.
It's really common to have a List of values with types like Option, Xor, or Validated that you would like to turn "inside out" into an Option (or Xor or Validated) of a List. The sequence, sequenceU, traverse, and traverseU methods are really handy for this. You can read more about them in the [Traverse documentation]({{ site.baseurl }}/tut/traverse.html).
Cats defines and implements numerous type classes. Unfortunately, encoding these type classes in Scala can incur a large amount of boilerplate. To address this, Simulacrum introduces @typeclass, a macro annotation which generates a lot of this boilerplate. This elevates type classes to a first class construct and increases the legibility and maintainability of the code. Use of simulacrum also ensures consistency in how the type classes are encoded across a project. Cats uses simulacrum wherever possible to encode type classes, and you can read more about it at the project page.
Note that the one area where simulacrum is intentionally not used is in the cats-kernel module. The cats-kernel module is intended to be a shared dependency for a number of projects, and as such, it is important that it is both lightweight and very stable from a binary compatibility perspective. At some point there may be a transition from simulacrum to typeclassic, and the binary compatibility of moving between simulacrum and typeclassic is unclear at this point. Avoiding the dependency on simulacrum in cats-kernel, provides insulation against any potential binary compatibility problems in such a transition.
Cats defines a wealth of type classes and type class instances. For a number of the type class and instance combinations, there is a mismatch between the type parameter requirements of the type class and the type parameter requirements of the data type for which the instance is being defined. For example, the [Xor]({{ site.baseurl }}/tut/xor.html) data type is a type constructor with two type parameters. We would like to be able to define a [Monad]({{ site.baseurl }}/tut/monad.html) for Xor, but the Monad type class operates on type constructors having only one type parameter.
Enter type lambdas! Type lambdas provide a mechanism to allow one or more of the type parameters for a particular type constructor to be fixed. In the case of Xor then, when defining a Monad for Xor, we want to fix one of the type parameters at the point where a Monad instance is summoned, so that the type parameters line up. As Xor is right biased, a type lambda can be used to fix the left type parameter and allow the right type parameter to continue to vary when Xor is treated as a Monad. The right biased nature of Xor is discussed further in the [Xor documentation]({{ site.baseurl }}/tut/xor.html).
Enter kind-projector! kind-projector is a compiler plugin which provides a convenient syntax for dealing with type lambdas. The symbols ? and λ are treated specially by kind-projector, and expanded into the more verbose definitions that would be required were it not to be used. You can read more about kind-projector at the project page.
macro Ops invokes the Machinist Ops macro, and is used in cats in a number of places to enrich types with operations with the minimal possible cost when those operations are called in code. Machinist supports an extension mechanism where users of the macro can provide a mapping between symbolic operator names and method names. The cats.macros.Ops class uses this extension mechanism to supply the set of mappings that the cats project is interested in.
More about the history of machinist and how it works can be discovered at the project page, or this article on the typelevel blog.
The cats community welcomes and encourages contributions, even if you are completely new to cats and functional programming. Here are a few ways to help out:
- Find an undocumented method and write a ScalaDoc entry for it. See [Arrow.scala]({{ site.sources }}/core/src/main/scala/cats/arrow/Arrow.scala) for some examples of ScalaDoc entries that use sbt-doctest.
- Look at the code coverage report, find some untested code, and write a test for it. Even simple helper methods and syntax enrichment should be tested.
- Find an open issue, leave a comment on it to let people know you are working on it, and submit a pull request. If you are new to cats, you may want to look for items with the low-hanging-fruit label.
See the [contributing guide]({{ site.baseurl }}/contributing.html) for more information.