Skip to content

[Documentation] Trying to rewrite typeclasses-new #8147

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 29 commits into from
Mar 30, 2020
Merged
Changes from 8 commits
Commits
Show all changes
29 commits
Select commit Hold shift + click to select a range
a5c8aef
trying to rewrite typeclasses-new
Jan 6, 2020
1bd517e
Wrap the last sentence in a whole "summary" section to avoid stray text
Jan 31, 2020
171a09a
Step2: rewrite the Functor part in more details
Jan 31, 2020
6b7e497
Step3: rewrite the Monad part (apart from the Reader monad)
Jan 31, 2020
74ff540
Fix typos
Jan 31, 2020
8118ed7
Rephrase assertTransformation simplification
Jan 31, 2020
a076eea
Fix typos on the reader monad
Jan 31, 2020
66ebcfb
@bishabosha's note
Jan 31, 2020
334c4b4
attempt at explaining the reader monad
Jan 31, 2020
cd501b6
less concrete and more accurate definition of a Functor
aesteve Jan 31, 2020
ff7ca15
definition of A functor, not THE functor ability
aesteve Jan 31, 2020
cf29e82
A functor for the type constructor F[_]
aesteve Jan 31, 2020
8607014
better phrasing for abstracting away Config
aesteve Jan 31, 2020
4c81c46
parameterised type with abstract members => trait
aesteve Jan 31, 2020
6b6cd39
oo polymorphism vs. parametric polymorphism
aesteve Jan 31, 2020
c6ec581
explaining the difference between OO polymorphism and ad-hoc polymorp…
aesteve Jan 31, 2020
716ae0c
better phrasing for conclusion
aesteve Jan 31, 2020
c15cd63
remove the "we don't care" part
aesteve Jan 31, 2020
8b85b34
using F as a substitution for every type that ca be mapped over
aesteve Jan 31, 2020
86615f6
Merge remote-tracking branch 'upstream/master' into doc/rework-typecl…
Feb 9, 2020
f2d7a6d
Merge remote-tracking branch 'origin/doc/rework-typeclasses-new' into…
Feb 9, 2020
df15a24
Trying to add an easy-to-grasp definition of type classes
Feb 9, 2020
4b04603
Proper 0.23 syntax
Feb 10, 2020
cb6c511
Proper 0.23 syntax
Feb 10, 2020
cd9834e
typo
Feb 10, 2020
bf7b005
no longer `given as`
Feb 10, 2020
9c1509b
typeclasses-new.md is now typeclasses.md
Feb 13, 2020
466bff9
Adapt to 0.23 latest
Feb 26, 2020
219bc3c
Use new type wildcard syntax
Mar 30, 2020
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
185 changes: 170 additions & 15 deletions docs/docs/reference/contextual/typeclasses-new.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,12 +3,13 @@ layout: doc-page
title: "Implementing Typeclasses"
---

Given instances, extension methods and context bounds
allow a concise and natural expression of _typeclasses_. Typeclasses are just traits
with canonical implementations defined by given instances. Here are some examples of standard typeclasses:
In Scala 3, _typeclasses_ are just traits whose implementation are defined by given instances.
Here are some examples of standard typeclasses:

### Semigroups and monoids:

Here's the `Monoid` typeclass definition:

```scala
trait SemiGroup[T] {
@infix def (x: T) combine (y: T): T
Expand All @@ -17,50 +18,204 @@ trait SemiGroup[T] {
trait Monoid[T] extends SemiGroup[T] {
def unit: T
}
```

object Monoid {
def apply[T] with (m: Monoid[T]) = m
}
An implementation of this `Monoid` typeclass for the type `String` can be the following:

```scala
given as Monoid[String] {
def (x: String) combine (y: String): String = x.concat(y)
def unit: String = ""
}
```

Whereas for the type `Int` one could write the following:
```scala
given as Monoid[Int] {
def (x: Int) combine (y: Int): Int = x + y
def unit: Int = 0
}
```

def sum[T: Monoid](xs: List[T]): T =
This monoid can now be used as _context bound_ in the following `combineAll` method:

```scala
def combineAll[T: Monoid](xs: List[T]): T =
xs.foldLeft(summon[Monoid[T]].unit)(_ combine _)
```

To get rid of the `summon[...]` we can define a `Monoid` object as follows:

```scala
object Monoid {
def apply[T] with (m: Monoid[T]) = m
}
```

Which would allow to re-write the `combineAll` method this way:

```scala
def combineAll[T: Monoid](xs: List[T]): T =
xs.foldLeft(Monoid[T].unit)(_ combine _)
```

### Functors and monads:
We can also benefit from [extension methods](extension-methods-new.html) to make this `combineAll` function accessible as a method on the `List` type:


```scala
def [T: Monoid](xs: List[T]).combineAll: T =
xs.foldLeft(Monoid[T].unit)(_ combine _)
```

Which allows one to write:

```scala
assert("ab" == List("a", "b").combineAll)
```
or:
```scala
assert(3 == List(1, 2).combineAll)
```

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this, it's a lot more with the style of the rest of the documentation. If you apply the same style to the Functors and Monads section this will be really nice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK I'm not sure I have enough knowledge to re-write the Functor/Monad part in the same fashion (you need to understand properly to explain properly) but I will definitely give it a try.
If I'm struggling I'll ping you, so that you know you can merge this as is (best if the ennemy of good ;) ). But that's worth trying.

### Functors:

A `Functor` represents the ability for a type containing zero or more elements to be "mapped over", i.e. apply a function to every of its elements.
Let's name our "type containing zero or more elements" `F`. It's a type constructor: the type of its values becomes concrete when provided a type argument.
Therefore we'll write it `F[_]` since we don't really care about the type of the elements it contains.
The definition of the `Functor` ability would thus be written as:

```scala
trait Functor[F[_]] {
def map[A, B](original: F[A], mapper: A => B): F[B]
}
```

Which could read as follows: "The `Functor` ability for a wrapper type `F` represents the ability to transform `F[A]` to `F[B]` through the application of the `mapper` function whose type is `A => B`".
This way, we could define an instance of `Functor` for the `List` type:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This way, we could define an instance of `Functor` for the `List` type:
This way, we could define an instance of `Functor` for the `List` type constructor:


```scala
given as Functor[List] {
def map[A, B](original: List[A], mapper: A => B): List[B] =
original.map(mapper) // List already has a `map` method
}
```

With this `given` instance in scope, everywhere a `Functor` is expected, the compiler will accept a `List` to be used.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
With this `given` instance in scope, everywhere a `Functor` is expected, the compiler will accept a `List` to be used.
With this `given` instance in implicit scope, whenever a value of an abstract type with context bound of `Functor` is expected, a `List` value can be provided.


For instance, we may write such a testing method:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idk, too many instance words floating around

Suggested change
For instance, we may write such a testing method:
As a concrete use case, we may write a testing method with such a bound:

```scala
def assertTransformation[F[_]: Functor, A, B](expected: F[B], original: F[A], mapping: A => B): Unit =
assert(expected == summon[Functor[F]].map(original, mapping))
```

And use it this way, for example:

```scala
assertTransformation(List("a1", "b1"), List("a", "b"), elt => s"${elt}1")
```

That's a first step, but in practice we probably would like the `map` function to be a method directly accessible on the type `F`. So that we can call `map` directly on instances of `F`, and get rid of the `summon[Functor[F]]` part.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
That's a first step, but in practice we probably would like the `map` function to be a method directly accessible on the type `F`. So that we can call `map` directly on instances of `F`, and get rid of the `summon[Functor[F]]` part.
That's a first step, but in practice we probably would like the `map` function to be a method directly accessible on concrete instances of `F[_]`. So that we can call `map` directly, and get rid of the `summon[Functor[F]]` part.

As in the previous example of Monoids, [`extension` methods](extension-methods-new.html) help achieving that. Let's re-define the `Functor` _typeclass_ with extension methods.

```scala
trait Functor[F[_]] {
def [A, B](x: F[A]).map(f: A => B): F[B]
def [A, B](original: F[A]).map(mapper: A => B): F[B]
}
```

The instance of `Functor` for `List` now becomes:

```scala
given as Functor[List] {
def [A, B](original: List[A]).map(mapper: A => B): List[B] =
original.map(mapper) // List already has a `map` method
}
```

It simplifies the `assertTransformation` method:

```scala
def assertTransformation[F[_]: Functor, A, B](expected: F[B], original: F[A], mapping: A => B): Unit =
assert(expected == original.map(mapping))
```

The `map` method is now directly used on `original` since it is of type `F[A]` (where `F` is a `Functor`).


### Monads

Now we have a `Functor` for `List`.

Applying the `List.map` ability with the following mapping function as parameter: `mapping: A => B` would result in a `List[B]`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Applying the `List.map` ability with the following mapping function as parameter: `mapping: A => B` would result in a `List[B]`.
Using our `Functor` to call `map` on a `List[A]` with an argument of type `A => B` would result in obtaining a `List[B]`.


Now, applying the `List.map` ability with the following mapping function as parameter: `mapping: A => List[B]` would result in a `List[List[B]]`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Now, applying the `List.map` ability with the following mapping function as parameter: `mapping: A => List[B]` would result in a `List[List[B]]`.
If instead, we map with a function `A => List[B]`, we would get a `List[List[B]]`.


trait Monad[F[_]] extends Functor[F] {
def [A, B](x: F[A]).flatMap(f: A => F[B]): F[B]
def [A, B](x: F[A]).map(f: A => B) = x.flatMap(f `andThen` pure)
To avoid avoid managing lists of lists, we may want to "flatten" the values in a single list.

def pure[A](x: A): F[A]
That's where `Monad` enter the party. A `Monad` for type `F[_]` is a `Functor[F]` with 2 more abilities:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
That's where `Monad` enter the party. A `Monad` for type `F[_]` is a `Functor[F]` with 2 more abilities:
That's where `Monad` enters the party. A `Monad` for type `F[_]` is a `Functor[F]` with 2 more capabilities:

* the flatten ability we just described: turning `F[A]` to `F[B]` when given a `mapping: A => F[B]` function
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* the flatten ability we just described: turning `F[A]` to `F[B]` when given a `mapping: A => F[B]` function
* the flatten capability we just described: turning `F[A]` to `F[B]` when given a `mapping: A => F[B]` function

* the ability to create `F[A]` from a single value `A`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* the ability to create `F[A]` from a single value `A`
* the ability to create `F[A]` from a single value `A`.
Together, these capabilities extend `Functor` to allow transformation of values that can change their shape. For example, dropping or adding elements to a collection.


Here is the translation of this definition in Scala 3:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Here is the translation of this definition in Scala 3:
Here is how we extend our `Functor` definition with the new capabilities:


```scala
trait Monad[F[_]] extends Functor[F] { // "A `Monad` for type `F[_]` is a `Functor[F]`" => thus has the `map` ability
def pure[A](x: A): F[A] // `pure` can construct F[A] from a single value A
def [A, B](x: F[A]).flatMap(f: A => F[B]): F[B] // the flattening ability is named `flatMap`, using extension methods as previous examples
def [A, B](x: F[A]).map(f: A => B) = x.flatMap(f `andThen` pure) // the `map(f)` ability is simply a combination of applying `f` then turning the result into an `F[A]` then applying `flatMap` to it
}
```

#### List

Let us declare the `Monad` ability for type `List`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Let us declare the `Monad` ability for type `List`
Let us declare a `Monad` for `List`:

```scala
given listMonad as Monad[List] {
def [A, B](xs: List[A]).flatMap(f: A => List[B]): List[B] =
xs.flatMap(f)
def pure[A](x: A): List[A] =
List(x)
def [A, B](xs: List[A]).flatMap(f: A => List[B]): List[B] =
xs.flatMap(f) // let's rely on the existing `flatMap` method of `List`
}
```

`map` implementation is no longer needed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`map` implementation is no longer needed.
If we only defined a `Monad` for `List`, then a default implementation of `map` is already provided, as `map` on `List` is equivalent to a combination of `flatMap` and `pure`.


#### Option

`Option` is an other type having the same kind of behaviour:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`Option` is an other type having the same kind of behaviour:
`Option` is another type that has a definition for `Monad`:

* the `map` ability turning `Option[A]` into `Option[B]` if passed a function `f: A => B`
* the `flatMap` ability turning `Option[A]` into `Option[B]` if passed a function `f: A => Option[B]`
* the `pure` ability turning `A` into `Option[A]`

```scala
given optionMonad as Monad[Option] {
def pure[A](x: A): Option[A] =
Option(x)
def [A, B](xs: Option[A]).flatMap(f: A => Option[B]): Option[B] =
xs.flatMap(f) // let's rely on the existing `flatMap` method of `Option`
}
```

#### The Reader Monad

Another example of a `Monad` is the Reader Monad. It no longer acts on a type like `List` or `Option`, but on a function.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Another example of a `Monad` is the Reader Monad. It no longer acts on a type like `List` or `Option`, but on a function.
Another example of a `Monad` is the reader monad. It doesn't act on a collection such as `List` or `Option`, but a function.

It can be used for example for combining functions that all need the same type of parameter. For instance multiple functions needing access to some configuration, context, environment variables, etc.

The Reader monad allows to abstract over such a configuration dependency (or context, environment, ...), named `Ctx` in the following examples. It is therefore _parameterized_ by `Ctx`:

```scala
given readerMonad[Ctx] as Monad[[X] =>> Ctx => X] {
def [A, B](r: Ctx => A).flatMap(f: A => Ctx => B): Ctx => B =
ctx => f(r(ctx))(ctx)
def pure[A](x: A): Ctx => A =
ctx => x
}
```

### Summary

The definition of a _typeclass_ is expressed in Scala 3 via a `trait`.
The main difference with other traits resides in how these traits are implemented.
In the case of a _typeclass_ the trait's implementations are expressed through `given ... as` type definitions, and not through classes that `extends` the trait linearly.

In addition to these given instances, other constructs like extension methods, context bounds and type lambdas allow a concise and natural expression of _typeclasses_.