Skip to content

Commit

Permalink
Slight clean up of State docs (typelevel#2226)
Browse files Browse the repository at this point in the history
They now use `tut:silent` in a few places that they were previously
using `tut:book` to make the output a bit less noisy for code with an
uninteresting result (like imports or defining a method).
  • Loading branch information
ceedubs authored and kailuowang committed Apr 13, 2018
1 parent 350c683 commit bee3329
Show file tree
Hide file tree
Showing 2 changed files with 7 additions and 7 deletions.
12 changes: 6 additions & 6 deletions docs/src/main/tut/datatypes/state.md
Original file line number Diff line number Diff line change
Expand Up @@ -196,7 +196,7 @@ This may seem surprising, but keep in mind that `b` isn't simply a `Boolean`. It
## Interleaving effects

Let's expand on the above example; assume that our random number generator works asynchronously by fetching results from a remote server:
```tut:book
```tut:silent
import scala.concurrent.Future
import scala.concurrent.ExecutionContext.Implicits.global
Expand Down Expand Up @@ -228,7 +228,7 @@ The `seed` that `State.apply` passes in is now a `Future`, so we must map it. Bu
Luckily, `State[S, A]` is an alias for `StateT[Eval, S, A]` - a monad transformer defined as `StateT[F[_], S, A]`. This data type represents computations of the form `S => F[(S, A)]`.

If we plug in our concrete types, we get `AsyncSeed => Future[(AsyncSeed, A)]`, which is something we can work with:
```tut:book
```tut:silent
import cats.data.StateT
import cats.instances.future._
import scala.concurrent.ExecutionContext.Implicits.global
Expand All @@ -250,7 +250,7 @@ It should be noted that different combinators on `StateT` impose different const
## Changing States

More complex, stateful computations cannot be easily modeled by a single type. For example, let's try to model a door's state:
```tut:book
```tut:silent
sealed trait DoorState
case object Open extends DoorState
case object Closed extends DoorState
Expand All @@ -262,8 +262,8 @@ def close: State[DoorState, Unit] = ???
```

We would naturally expect that `open` would only operate on doors that are `Closed`, and vice-versa. However, to implement these methods currently, we have to pattern-match on the state:
```tut:book
def open: State[DoorState, Unit] = State { doorState =>
```tut:silent
val open: State[DoorState, Unit] = State { doorState =>
doorState match {
case Closed => (Open, ())
case Open => ??? // What now?
Expand All @@ -278,7 +278,7 @@ The most elegant solution would be to model this requirement statically using ty
This data type models a stateful computation of the form `SA => F[(SB, A)]`; that's a function that receives an initial state of type `SA` and results in a state of type `SB` and a result of type `A`, using an effect of `F`.

So, let's model our typed door:
```tut:book
```tut:silent
import cats.Eval
import cats.data.IndexedStateT
Expand Down
2 changes: 1 addition & 1 deletion project/plugins.sbt
Original file line number Diff line number Diff line change
Expand Up @@ -13,4 +13,4 @@ addSbtPlugin("org.xerial.sbt" % "sbt-sonatype" % "2.0")
addSbtPlugin("com.47deg" % "sbt-microsites" % "0.7.17")
addSbtPlugin("com.dwijnand" % "sbt-travisci" % "1.1.1")
addSbtPlugin("org.lyranthe.sbt" % "partial-unification" % "1.1.0")
addSbtPlugin("org.tpolecat" % "tut-plugin" % "0.6.3")
addSbtPlugin("org.tpolecat" % "tut-plugin" % "0.6.4")

0 comments on commit bee3329

Please sign in to comment.