anchor.diff:  
   Instead of letting the even function recursively call odd, we could also let it return some recipe to it's caller, how to continue with the computation. Let's look at the following code:
   
  -```
  +[source, scala]
  +----
   sealed trait EvenOdd
   case class Done(result: Boolean) extends EvenOdd
   case class Even(value: Int) extends EvenOdd
  
positive.code: case 0 => false
  case _ => even(i - 1)
  }
  ```
  
  We've defined even in a very natural way: an value is `even` when it's zero, or when it's `odd` after subtracting one. `Odd` is defined in a similar way.
  
  
negative.code: 
  Many recursive algorithms can be rewritten in a tail recursive way. For our even and odd problem, this is a possible solution:
  
  [source, scala]
  ----
  def even(i: Int): Boolean = i match {
  case 0 => true
  case 1 => false
  case _ => even(i - 2)
  }
  def odd(i: Int): Boolean = !even(i)
  ----
  
  We've rewritten `even` to be tail-recursive, and now Scala will optimize it for us:
  
  ```
  scala> even(500000000)
  res25: Boolean = true
  ```
  it no longer blows up for large numbers.
  
  
  The `@tailrec` annotation is useful in these cases. It does not change how the function will be compiled, but it does trigger an error if the function is not actually tail-recursive. So this will protect you from accidentally changing a function that you want to be tail-recursive function into something that's no longer tail recursive.
  
  