anchor.diff:  // Int => Int
   def plusOne(x: Int): Int = x+1
   ----
  +
   As you can see our pure code is completely decoupled from the side effect code (this is what functional programmers like to brag all the time about, pushing the side effects from our pure code). But now in order to use our pure function with a Maybe integer we need to add some methods.
  +
   [source,scala]
   ----
   trait Maybe[+A] { 
  -def value: A 
  -def isDefined: Boolean 
  -def map(f: A=>B): Maybe[B] = {  
  -if(isDefined) Just(f(value)) else NotThere  
  -}
  +	def value: A 
  +	def isDefined: Boolean 
  +	def map(f: A=>B): Maybe[B] = {  
  +		if(isDefined) Just(f(value)) else NotThere  
  +	}
   }
   
   case class Just[A](value: A) extends Maybe[A] {
  -def isDefined: Boolean = true
  +	def isDefined: Boolean = true
   }
   
   case object NotThere extends Maybe[Nothing] {
  -def isDefined: Boolean = false
  +	def isDefined: Boolean = false
   }
   ----
   
   So the important function that we added here is `map(f: A=> B): Maybe[B]`, as you can see is a higher order function because it takes an other function (our pure functions), and will only apply them to the value if and only if the value is defined. Now lets make a useful companion object: 
   And using our `plusOne` pure function, what we can do is 
   something like this:
  +
   [source,scala]
   ----
   val x: Int = 8
   val maybeX = Maybe(x).map(plusOne)
   > maybeX: Maybe[Int] = Just(9)
   ----
  +
   Now what if `x` was actually a null value? well then `maybeX: Maybe[Int] = NotThere` and no horrible null pointer exception is thrown, also we can handle that or exit the `Maybe` wrapper like this:
  +
   [source,scala]
   ----
   val x: Int = 8
   val y = Maybe(x).map(plusOne) match {
  -case Just(i) => i 
  -case NotThere => 0
  +	case Just(i) => i 
  +	case NotThere => 0
   }
   > maybeX: Int = 9
   ----
   Now lets realise that our true operation (the `plusOne` function) was kept nice and pure, and handling null values is now completely decoupled from all the countless functions that potentially could have ended with a terrible:
  +
   [source,scala]
   ----
   if (x == null)
   ...else ...
   ----
  +
   Also do not worry about coding all of these, since Scala already comes with these implemented:
  -Our Code   Scala
  +
   [source,scala]
   ----
   Maybe[A] = Option[A]
   Just(a)  = Some(a)
   NotThere = None
   ----
  +
   == Handling Side Effects v2: Functors
  +
   There is yet another spicy concept from functional programming that we will talk about: Functors. And we actually just created one! The formal definition of a functor is actually a little bit misleading as how they are used in software engineering, so lets keep it informal for now (as much as it pains). 
   
   If a normal function is a mapping from a thing A to a thing B, then analogously a functor is a mapping inside a higher kinded type F[A] to F[B]. In this case the F[\_] is the "higher kinded type" because it requires another type to become a type itself, for example our Maybe[\_] type. The Maybe `map` function is what it makes it a functor, since we are in the end going from some Maybe[A] to another Maybe[B].
   
   We could even abstract and decouple the concept of a Functor like this:
  +
   [source,scala]
   ----
   trait Functor[F[_]] { 
  -def map[A, B](fa: F[A])(f: A => B): F[B]
  +	def map[A, B](fa: F[A])(f: A => B): F[B]
   }
   ----
  +
   You can see this as a functional design pattern, using Functors to decouple side effects from our pure functions. Other functors implemented by the scala library are: 
  +
   [source,scala]
   ----
   List[_]
  
positive.code: Try[_]
  Either[_, _]
  ----
  And with functional libraries like `scalaz` or `cats` you will find many more that handle other type of side effects.
  
  == Conclusion
  Side effects can become the real arch enemy of programmers, but with powerful functional design patterns we can control them and create type safe, reliable programs. We will see in the next post an even more powerful design patter that derives from the need of controlling side effect, the always famous Monad.
  
  
  
negative.code: And why is it useful? Because it is completely deterministic, if you have a function `Int=>Int` you know that it will only accept integers, and that it will always give back an integer, and this actually communicates a lot, for example lets read this function:
  [source,scala]
  ----
  // Boolean => Boolean 
  def f(x: Boolean): Boolean
  ----
  
  How many implementations of this function can there possible be? Only two, either the identity function, or the negation function, because if you have a boolean, the only thing that we can do with it is either leave it like that or change it to the only other possible value.
  