anchor.diff:  
   In the previous article, we saw that it was perfectly possible to use a list to represent optional data. Absence of data is represented by an empty list, and data is represented by a singleton list. The main problem is that there was no mean to differentiate a normal list from a singleton list. The good thing is that it is very easy to compose both.
   
  -Another possibility is to use a special class to represent singleton lists. We might call this class `Option`. It will be identical to the `List` class, with two main exceptions: there is no `cons` method (since we can't add elements) and the folding methods generally do not take a function argument (although it could) and will simply return either the included value, if it is present, or the "zero" value if not. Of course, the zero value will have a more explicit name such as `default`, but this (like names in general) is irrelevant. Here is a minimal `Option` class:
  +Another possibility is to use a special class to represent singleton lists. We might call this class `Option`. It will be identical to the `List` class, with two main exceptions: there is no `cons` method (since we can't add elements) and the folding methods generally do not take a function argument. It could however take one, but it would in most use cases be the identity function, which is why it is most often implemented without this function argument. This method will then simply return either the included value, if it is present, or the "zero" value if not. Of course, the "zero" value will have a more explicit name such as `default`, but this (like names in general) is irrelevant. Here is a minimal `Option` class:
   
   [source,java]
   ----
  
positive.code: 
  == What Option changes to our example
  
  Using `Option` to represent optional data instead of a list brings some benefits in the sense that a program is often easier to read if we can easily distinguish between true lists (which can containing any number of elements) and singleton lists representing optional data (which can only contain zero or one element). By the way, the difference is not always visible since type may sometimes be inferred, such as when chaining methods. Here is our `pack` method using `Option` instead of `List` for optional data:
  
  [source,java]
  ----
  
negative.code: }
  ----
  
  (1) The flatMap method can't be used, since it produces a `List` Here, we produce an `Option`, but this would not be visible if we had kept the name `flatMap` for the method. We will of course have to define the `Option.sequence` method.
  
  (2) The `map` method is called on an `Option`, but it is difficult to see by looking at the code!
  
  (3) Getting the value (if present) or a default value (if not) is done through the `getOrElse` method. We changed the name to follow current usage although it is implemented through a fold!
  
  (4) We can simplify getting the value or default value from the resulting `Option`.
  
  The `map` and `getOrElse` method can be seen in the previous listing of the `Option` class. You can see that `Option` is really a `List`. The problem happens when a list is mapped with a function returning an `Option`. When we were using a list for optional data, the function was returning a `List`, so we ended with a `List<List<A>>`. Getting a `List<A>` instead was just a matter of using `flatMap` instead of `Map`. With `Option`, we end with a `List<Option<A>`. So we have to create a method for this. We will put it in the `List` class. By convention, this method is called `sequence`. In order to better mimic the `List.flatMap` method, we will also add a convenience `sequence` method taking a function returning an `Option` as its argument:
  
  [source,java]
  ----
  