anchor.diff:  * Statically typed signatures enable implementations to detect possible type errors at query compilation time.
   * Statically typed signatures also allow us to add support for procedure overloading in the future.
   
  -To support these goals, it is necessary to at least introduce syntax for all valid, supported public types as well as syntax for type annotation.
  +To support these goals, it is necessary to at least define all valid, supported public types, introduce syntax for them as well as syntax for type annotations.
   
   === Overview
  -For the purposes of this CIP, a type system is a system of classifying expressions according to what kinds of values they may evaluate to during the execution of a Cypher query.
  -It does *not *include a specification of a type inferencing and checking algorithm for Cypher queries.
  +For the purposes of this CIP, a type system is a system of classifying expressions according to what kinds of values they may evaluate to during the execution of a Cypher query. Furthermore, for a given type system, a type annotation enables annotating terms with type expectations for later re-use in determining the type of other expressions (e.g. when determining the type of a function call expression and its arguments based on type annotations used in function signatures). The type system presented in this CIP does not include a specification of a type inferencing and checking algorithm for Cypher queries (out of scope).
   
   Cypher today has a rich type system that unifies Java implementation types into a coherent type hierarchy and an accompanying type checker that supports rich types with https://en.wikipedia.org/wiki/TypeParameter[type parameters] and https://en.wikipedia.org/wiki/Union_type[union types].
   So far it has not been possible to explicitly specify the type of an expression in a query.
   
  -This CIP proposes to introduce syntax for type literals and for type annotations for public types.
  -Any implementation may choose to incorporate a set of internal types beyond those specified here.
  -All such internal types must map cleanly onto the public type system and should generally not be made visible to end users.
  +This CIP proposes to introduce a well defined type system, syntax for type literals and for type annotations for public
  +types. Any implementation may choose to incorporate a set of internal types beyond those specified here. All such
  +internal types must map cleanly onto the public type system and should generally not be made visible to end users.
  +
   The details of internal types are out of scope for the purposes of this document.
   
   == Proposal
  
positive.code: ----
  type = scalar type
       | container type
       | optional type
       ;
  
  optional type = type, "?" ;
  
  scalar type   = "Any"
                | "Boolean"
                | "Integer"
                | "Float"
                | "Map"
                | "Node"
                | "String"
                | "Relationship"
                | "Path"
                | "Number"
                | "DateTime"
                | "LocalDateTime"
                | "Date"
                | "LocalDate"
                | "LocalTime"
                | "Duration"
                ;
  
  container type = "LIST", "<", type, ">" ;
  
  type annotation = term, "::", type ;
  ----
  
  === Semantics
  This CIP only provides syntax for future CIPs, it does not directly change Cypher and therefore does not change semantics.
  
  The intended use of type annotations is that they express that the annotated term either has, evaluates to, or is coerced to a value of the annotated type.
  
  === Interaction with existing features
  This CIP adds new keywords for all type names.
  It is expected that these type name keywords are only valid in specific contexts in the grammar (mostly in type annotations but also possibly in operators).
  The likelihood of conflict with existing (or future) production rules is therefore minimal.
  
  === Alternatives
  
  ==== Type Literal Syntax
  As part of writing this CIP, many syntax alternatives have been considered for type literal syntax:
  
  * Alternative name for the `STRING` type: `TEXT`, `UNICODE`, `LIST<CHAR>`
  * Alternative name for the `LIST` type: `ARRAY`, `COLLECTION`, `SEQUENCE`, `VECTOR`
  * Alternative syntax for type parameters: `LIST OF T`, `LIST[T]`, `LIST<T>`, `LIST T`
  * Alternative syntax for type annotations: `(STRING) expr`, `STRING expr`, `expr: `T`
  
  === Type Annotation Syntax
  
  
  == What others do
  
  
negative.code: 
  The sections below list all types available at the time of acceptance of this CIP.
  
  ==== Material Core Types
  
  The following material (non-nullable) core types should be supported by any implementation of Cypher
  
   * `ANY`
   ** Parent of all types
   * `BOOLEAN`
   ** true and false
   * `STRING`
   ** Unicode Strings, i.e. `"Cypher"`, and `‘text’`
   * `NUMBER`
   ** Parent of all numeric types (i.e. `INTEGER` and `FLOAT`)
   * `INTEGER`
   ** Exact numbers without decimals, i.e. -3, 0, 4
   * `FLOAT`
   ** IEEE-754 64-bit floating point numbers
   * `MAP`
   ** Maps from strings to values of any type, i.e. `{ name: "Svensson" }`. Parent to all property containers, like `NODE` and `RELATIONSHIP`
   * `LIST OF T`
   ** Lists (ordered sequences with random access) of a given type T
   ** `LIST OF T2` is a subtype of `LIST OF T1` if `T2` is a subtype of `T1`. This works since values in Cypher are immutable. Adding an element of type `T` to a `LIST OF S` would produce a new list of type `LIST OF R`, where `R` is the nearest common supertype of `T` and `S`
   * `NODE`
   ** A `NODE` is a node in the property graph model with properties, labels, and relationships. A node is an entity and a property container and therefore also a `MAP`.
   * `RELATIONSHIP`
   ** A `RELATIONSHIP` is a relationship in the property graph model with properties, relationship type, a start node, and an end node. A relationship is an entity and a property container and therefore also a `MAP`.
   * `PATH`
   ** A path from a node `n1` to a node `ni` - corresponding to a walk in the graph from `n1` to `ni` - is a sequence `n1`, `r1`, `n2`, `r2`, ..., `r(i-1)`, `ni` of alternating nodes and relationships such that for 1 <= `j` < `i`, any `rj` contained in the path is incident with `nj` and `n(j+1)`. Additionally, a single node path is a path that starts and ends at the same node `n0` and does not contain any relationships.
  
  ==== Date and Time Types
  
  The following material scalar types should be supported by any implementation of Cypher in accordance with _CIP2015-08-06 - Date and Time_.
  
   * `DATETIME`
   ** An instant capturing the date, the time, and the timezone.
   * `LOCALDATETIME`
   ** An instant capturing the date and the time, but not the time zone.
   * `DATE`
   ** An instant capturing the date, but not the time, nor the time zone.
   * `TIME`
   ** An instant capturing the time of day, and the timezone, but not the date.
   * `LOCALTIME`
   ** An instant capturing the time of day, but not the date, nor the time zone.
   * `DURATION`
   ** A temporal amount. This captures the difference in time between two instants. It only captures the amount of time between two instants, it does not capture a start time and end time. A duration can be negative.
  
  ==== Nullable Types
  
  The type system also provides a way to track nullability, i.e. a type may express if a given expression may be `NULL` or not. Non-nullable types are all types that do not permit `NULL` as a valid result of evaluating the underlying expression. All types specified above are material (non-nullable) types.
  
  Nullable types are all types that permit `NULL` as a valid result of evaluating the underlying expression. Nullable type names are formed by suffixing a material type name with a single question mark. Nullable variants of all material types should be supported by any implementation of Cypher. Note that `NULL` is not a type but a value that inhabits every nullable type.
  
  Every nullable type is a supertype of its underlying material type, i.e. `T?` is a supertype of `T`. By extension,
  if `S` is a supertype of `T`, then `S?` is also a supertype of `T`. As a consequence, `ANY?` is the most generic type available within Cypher and is the supertype of every possible value.
  
  ==== Reserved type names
  
  In addition to the types above, the following type names are reserved by this CIP for future use:
  
   * `BYTES`
   * `IDENTITY`
   * `POINT`
  
  === 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
  
  