Scalaz

Scalaz is a Scala library for functional programming.

It provides purely functional data structures to complement those from the Scala standard library. It defines a set of foundational type classes (e.g. Functor, Monad) and corresponding instances for a large number of data structures.

Getting Scalaz

The current stable version is 7.2.27, which is cross-built against Scala 2.10.x, 2.11.x and 2.12.x.

If you're using SBT, add the following line to your build file:

libraryDependencies +="org.scalaz"%%"scalaz-core"%"7.2.27"

For Maven and other build tools, you can visit search.maven.org. (This search will also list all available modules of scalaz.)

To get sample configurations, click on the version of the module you are interested in. You can also find direct download links at the bottom of that page. Choose the file ending in 7.2.27.jar.

At a glance

Type class instances are no longer defined in the companion objects of the type class. Instances for standard library types are defined under scalaz.std, and instances for Scalaz data types are defined in the companion object for those types. An instance definition can provide multiple type classes in a single place, which was not always possible in Scalaz 6.

Type class instances have been organized to avoid ambiguity, a problem that arises when instances are dependent on other instances (for example, Monoid[(A, B)])

Use of implicit views to provide access to Scalaz functionality as extension methods has been segregated to scalaz.syntax, and can be imported selectively, and need not be used at all.

Related functions are defined in the type class trait, to support standalone usage of the type class. In Scalaz 6, these were defined in Identity, MA, or MAB.

New data structures have been added, and existing ones generalized. A number of monad transformers have been provided, in some cases generalizing old data structures.

Modularity

scalaz-effect: Data structures to represent and compose IO effects in the type system.

scalaz-iteratee: Experimental new Iteratee implementation

Type Class Hierarchy

Type classes form an inheritance hierarchy, as in Scalaz 6. This is convenient both at the call site and at the type class instance definition. At the call site, it ensures that you can call a method requiring a more general type class with an instance of a more specific type class:

The hierarchy itself is largely the same as in Scalaz 6. However, there have been a few adjustments, some method signatures have been adjusted to support better standalone usage, so code depending on these will need to be re-worked.

Type Class Instance Definition

Constructive implicits, which create a type class instance automatically based on instances of all parent type classes, are removed. These led to subtle errors with ambiguous implicits, such as this problem with FunctorBindApply

Type class instances are no longer declared in fragments in the companion objects of the type class. Instead, they are defined in the package scalaz.std, and must be imported. These instances are defined in traits which will be mixed together into an object for importing en-masse, if desired.

A single implicit can define a number of type class instances for a type.

Syntax

We co-opt the term syntax to refer to the way we allow the functionality of Scalaz to be called in the object.method(args) form, which can be easier to read, and, given that type inference in Scala flows from left-to-right, can require fewer type annotations.

No more Identity, MA, or MAB from Scalaz 6.

Syntax is segregated from rest of the library, in a sub-package scalaz.syntax.

All Scalaz functionality is available without using the provided syntax, by directly calling methods on the type class or its companion object.

Syntax is available a-la-carte. You can import the syntax for working with particular type classes where you need it. This avoids flooding the autocompletion in your IDE with every possible extension method. This should also help compiler performance, by reducing the implicit search space.

Syntax is layered in the same way as type classes. Importing the syntax for, say, Applicative will also provide the syntax for Apply and Functor.

Syntax can be imported in two ways. Firstly, the syntax specialized for a particular instance of a type class can be imported directly from the instance itself.

For some degree of backwards compatibility with Scalaz 6, the über-import of import scalaz.Scalaz._ will import all implicit conversions that provide syntax (as well as type class instances and other functions). However, we recommend to review usage of this and replace with more focussed imports.

Standalone Type Class Usage

Type classes should be directly usable, without first needing to trigger implicit conversions. This might be desirable to reduce the runtime or cognitive overhead of the pimped types, or to define your own pimped types with a syntax of your choosing.

The methods in type classes have been curried to maximize type inference.

Derived methods, based on the abstract methods in a type class, are defined in the type class itself.

Each type class companion object is fitted with a convenient apply method to obtain an instance of the type class.

// Equivalent to `implicitly[Monad[Option]]`valO=Monad[Option]
// `bind` is defined with two parameter sections, so that the type of `x` is inferred as `Int`.O.bind(Some(1))(x =>Some(x *2))
defplus(a: Int, b: Int) = a + b
// `Apply#lift2` is a function derived from `Apply#ap`.valplusOpt=O.lift2(plus)

Type Class Instance Dependencies

Type class instances may depend on other instances. In simple cases, this is as straightforward as adding an implicit parameter (or, equivalently, a context bound), to the implicit method.

The method OptionT#map requires an implicit parameter of type Functor[F], whereas OptionT#flatMap requires one of type Monad[F]. The capabilities of OptionT increase with those of F. We need to encode this into the type class instances for [a]OptionT[F[A]].

In case of ambiguous implicits, Scala will favour one defined in a sub-class of the other. This is to avoid ambiguity when in cases like the following:

typeOptionTList[A] =OptionT[List[A]]
implicitly[Functor[OptionTList]]
// Candidates:// 1. OptionT.OptionTFunctor[List](implicitly[Functor[List]])// 2. OptionT.OptionTMonad[List](implicitly[Functor[List]])// #2 is defined in a subclass of the enclosing class of #1, so #2 is preferred.

Transformers and Identity

A stronger emphasis has been placed on transformer data structures (aka Monad Transformers). For example State is now a type alias for StateT[Id, A, B].