anchor.diff:  This appendix captures the discussion around type syntax that was part of creating this CIP. It is informative only and not part of the proposal.
   It merely documents the authors' ideas for future use of types in Cypher.
   
  -=== Internal vs public types
  +=== Internal vs Public Types
   We distinguish between internal types and public types to minimize mental overhead and simplify language mapping.
   Internal types are tracked by the type checking algorithm.
   They may contain more sophisticated static analysis information such as nullability, which properties exist on a node, or alternative types for a value (union types).
  -A Cypher user commonly should not be required to be aware of internal types though they may influence behaviour or become visible in error messages.
  +A Cypher user commonly should not be required to be aware of internal types though they may influence behavior or become visible in error messages.
   Public types contain less information than internal types.
   They can be specified in type annotations and there should exist straightforward mappings between the public type system and type systems of target languages of officially supported drivers and the store.
   
  
positive.code: 
  === Type Annotation
  
  To specify the type type of a term term in future changes to the Cypher grammar, this CIP proposes using the following syntax
  
  [source, ebnf]
  ----
      term :: type
  ----
  
  ==== Type Literal Use Outside of Annotations
  
  Type literals could be used in other production rules as well where this is considered more readable by future CIPs (e.g. in a type test operator like `expr IS NUMBER`).
  
  
negative.code: 
  	   CAST ( <expr> AS <type> )
  
  There are some variations in how different implementations support casting.
  This is detailed below.
  
  ==== PostgreSQL
  Casting in PostgreSQL can be achieved by using cast functions in addition to the AS keyword:
  