anchor.diff:      on the reflection system to extrapolate serialization rules for
       each type (resulting in runtime errors if this is not possible).
   
  -  * There is confusion as to which is the prefered design pattern for serialization.
  +  * There is confusion as to which is the prefered methodology for when
  +    defining serialization semantics for new types.
       The BCL comes with a multitude of dated, unsafe, mutually exclusive
  -    and naturally inefficient patterns.
  +    and naturally inefficient approaches.
   
  -### BCL Serialization patterns
  +### BCL Serialization methods
   
   The BCL comes with the following patterns for defining serializable types:
   
     * Field-based serialization: objects are pickled by serializing the contents 
       of their fields. This behaviour is tuned by applying an assortment of attributes
  -    such as `Serialized`, `NonSerialized`, `OnSerializing`, `OnDeserialized`, etc and
  -    implementing the `IDeserializationCallback` interface. This is arguably the most
  -    loathed serialization pattern, since it is extremely sensitive to internal implementation details.
  -    Incidentally, this is the pattern of choice for most F# generated types.
  +    such as `Serialized`, `NonSerialized`, `OnSerializing`, `OnDeserialized` and
  +    the `IDeserializationCallback` interface. This is arguably the most
  +    problematic approach, since it is sensitive to internal implementation details.
  +    Incidentally, this is the pattern of choice for most F# types.
   
     * Property-based or [DataContract](http://msdn.microsoft.com/en-us/library/ms733127.aspx) 
       serialization: objects are pickled by serializing the contents
       of specially flagged properties. Properties should be settable and are usually required to be
       public. In most cases, a parameterless constructor is also necessary. Property-based serialization
  -    is probably the most popular pattern.
  +    is probably the most popular approach.
   
     * [ISerializable](http://msdn.microsoft.com/en-us/library/system.runtime.serialization.iserializable.aspx) 
       types: possibly intended as a type-safe replacement of field-based serialization.
       It fails to live up to this role, mostly due to the nature of interfaces; it still requires a
       special constructor for deserialization which, if missing, would result in a runtime error.
  -    It is a particularly verbose pattern, resulting in a lot of boilerplate code.
  +    It requires separate implementations for serialization and deserialization, often leading to bugs
  +    and introducing lots of boilerplate code.
       Its dynamic nature also makes it impossible to reason about the components it serializes a priori.
  -    It is however an indispensible pattern, since it is used by many BCL types, most important being
  -    exception types, whose metadata is impossible to replicate without `ISerializable`.
  +    It is however an indispensible pattern since it is used by many BCL types, most important being
  +    exceptions, whose metadata is impossible to serialize otherwise.
   
   ### Serialization Libraries
   
  -The BCL ships with a couple of general-purpose serializer libraries but these either suffer
  +The BCL ships with a couple of general-purpose serializer libraries but these suffer either
   from obsolescence (e.g. [BinaryFormatter](http://msdn.microsoft.com/en-us/library/system.runtime.serialization.formatters.binary.binaryformatter.aspx)) 
  -or are painfully slow ([NetDataContractSerializer](http://msdn.microsoft.com/en-us/library/system.runtime.serialization.netdatacontractserializer.aspx)).
  +or performance ([NetDataContractSerializer](http://msdn.microsoft.com/en-us/library/system.runtime.serialization.netdatacontractserializer.aspx)).
   
   Many third-party libraries have emerged attempting to address the issue of performance, some with success.
   However, experience shows that such libraries hardly achieve the level of generalization
  
positive.code: 
  (**
  
  The `Write` and `Read` functions represent serialization and deserialization implementations
  for values of type `'T`. The `WriteState` and `ReadState` objects enclose serialization state,
  such target/source streams and things like object id generators.
  
  *Pickler combinators* are functions that operate on picklers, generating picklers of more complex types.
  For instance, the following could be a pickler combinator for rank-1 arrays:
  
  *)
  
  
negative.code: serialize closures. The inherently intrinsic and arbitrary nature of closures means 
  that they are not supported by most serialization libraries.
  Initially we started using NetDataContractSerializer as our library of choice,
  but that eventually took its toll on overall performance,
  so we decided to build a new library from scratch.
  
  FsPickler was created with two goals in mind: performance and completeness.
  