anchor.diff:  
   (**
   
  -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.
  +The `Write` and `Read` functions represent serialization and deserialization 
  +implementations for values of type `'T`. When compared to other .NET serializers, 
  +picklers prove exceptionally fast since they directly handle the serialized value
  +without any reliance on reflection-based resolution.
   
  -*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:
  +Pickler combinators are functions that operate on picklers, generating picklers of more complex types. 
  +For instance, the following could be a pickler combinator implementation for rank-1 arrays:
   
   *)
   
  
positive.code:   * carries the `DataContract` attribute and all designated properties are of 
      serializable type and settable. Parameterless constructors or public properties are not required.
  
    * carries the `CustomPickler` attribute and an accompanying pickler factory method.
  
    * is neither of the above and all designated fields are of serializable type.
      Parameterless constructors or public fields are not required.
  
negative.code:     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 methodology for when
      defining serialization semantics for new types.
      The BCL comes with a multitude of dated, unsafe, mutually exclusive
      and naturally inefficient approaches.
  
  ### 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` 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 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 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
      exceptions, whose metadata is impossible to serialize otherwise.
  
  ### Serialization Libraries
  
  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 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
  