anchor.diff:  
   == Caveats to this proposal
   
  -Adopting this proposal may break some queries; specifically queries that depend on equality semantics of lists containing nulls.
  -It should be noted that we expect that most lists used in queries are constructed using `collect()`, which never outputs nulls.
  +Adopting this proposal may break some queries; specifically queries that depend on equality semantics of lists containing `null` values.
  +It should be noted that we expect that most lists used in queries are constructed using `collect()`, which never outputs `null` values.
   
  -=== Appendix: Comparability by Type
  +== Appendix: Comparability by Type
   
   The following table captures which types may be compared with each other such that the outcome is either `true` or `false`.
   Any other comparison will always yield `null` (except for `NaN`) which is handled as described above.
   
  -.Comparability by type
  +.Comparability of values of different types (`X` means the result of comparison will always return `true` or `false`)
   [frame="topbot",options="header,footer"]
   |===========================================================================================================================================
   |Type           | `NODE` | `RELATIONSHIP` | `PATH` | `MAP` | `LIST OF ANY?` | `STRING` | `BOOLEAN` | `NUMBER` | `INTEGER` | `FLOAT` | `VOID`
  
positive.code: 
  == Motivation
  
  There are currently a number of limitations and inconsistencies that this CIP will try to fix.
  
  - `ORDER BY` will fail with an error if the values passed to it have different types.
  - Various inconsistencies around equality semantics as exposed by `IN`, `=`, `DISTINCT`, and grouping
  - Unclear relationship between comparison operators, equality, and `ORDER BY`
  
  The difference between equality and equivalence in Cypher today is small and subtle, and limited to testing two instances of the value `null` to each other.
  
  - In equality, `null = null` is `null`
  - In equivalence, used by grouping and `DISTINCT`, instances of `null` are treated as being the same value
  
  This proposal aims to increase the difference between these two concepts, by making lists containing `null` values follow the same difference as the `null` values themselves.
  
  == Proposal
  
  Currently, Cypher has good semantics for equality within the primitive types (booleans, strings, integers, and floats) and maps.
  Furthermore, Cypher has good semantics for comparability and orderability for integers, floats, and strings, within the types.
  Between different types, however, the comparability is undefined, which is something we regard as a problem for certain combinations of values and types. Also comparability and orderability are not aligned with each other consistently
  
  We propose that comparability be defined between any pair of values, where the result of a comparison is `null`, unless otherwise specified.
  
  - Integers are compared according to their natural ordering.
  - Floats (excluding `NaN`s) are compared according to their natural ordering. Infinities are the highest/lowest values respectively.
  - Integers and floats are compared to each other according to their natural ordering.
  - Comparing any number to a `NaN` always yields `NaN`.
  - Booleans are compared such that `false < true`.
  - Strings are compared in dictionary order, i.e. characters are compared pairwise in order and characters missing in a shorter string are considered to be smaller than any other character. For example, `'a' < 'aa'`.
  - Lists are compared in dictionary order, i.e. list elements are compared pairwise in order and elements missing in a shorter list are considered to be smaller than any other value. For example, `[1] < [1,0]`.
  - Maps are compared as if they where lists of lists, where the inner lists are the key-value pairs of the maps, ordered in ascending sort order for the keys and omitting map entries where the value is `null`. Comparing a map to a value that is not a map always yields 'null'.
  - The comparison order for nodes (and relationships resp.) is undefined, and an implementation may choose an order for these freely, e.g. by using some kind of id. This order must not change during the execution of the query (i.e. it must be stable in the presence of updates). Comparing a node to a relationship always yields 'null'.
  - Paths are compared as if they where a list of alternating nodes and relationships of the path from the start node to the end node. Comparing a path to a value that is not a path always yields 'null'.
  - Comparing any other combination of values of different types would yield `null` (meaning "unknown" in the context of comparability).
  
  We further propose that orderability be defined between any pair of values, where the result is always `true` or `false`; i.e. always defined.
  To accomplish this, there must be a pre-determined type order and each value must fall under exactly one type in this order. We propose to use the following ascending global sort order:
  
  - `NODE`
  - `RELATIONSHIP`
  - `PATH`
  - `MAP`
  - `LIST OF ANY?`
  - `STRING`
  - `BOOLEAN`
  - `NUMBER` (`NaN` is treated as the largest number in orderability, i.e. it is put after positive infinity)
  - `VOID` (i.e. `null`)
  
  Within the types, orderability defers to comparability.
  
  The accompanying descending global sort oder is the same order in reverse (i.e. it runs from `VOID` to `NODE`).
  
  Finally, we propose to redefine how equality works for lists in Cypher today.
  The main issue is how Cypher deals with lists that contain the `null` value.
  To determine if two lists `l1` and `l2` are equal, we propose two simple tests, like so
  
  - `l1` and `l2` must have the same size, i.e. inversely `size(l1) <> size(l2>) => l1 <> l2`
  - the pairwise elements of both `l1` and `l2` must be equal, i.e.
  ----
  [a1, a2, ...] = [b1, b2, ...]
  <=>
  a1 = b1 && a2 = b2 && ...
  ----
  
  === Examples
  
  
negative.code: 
  === Alternatives
  
  Columns in SQL are always have a concrete type. This removes the need to define a global sort order between types. Standard SQL has no support for lists, maps, or graph structures and hence does not need to define semantics for them.
  SQL also treats comparisons involving `null` as returning `null`.
  
  PostgresSQL treats some numerical operations (like division by zero) that would compute a `NaN` as a numerical error that fails the query. PostgresQL considers `NaN` to be larger than positive infinity, both in comparison and in sort order. This proposal achieves something very similar by evaluating comparisons involving a `NaN` to `null` and by treating both `NaN` and `null` as the largest values in the global sort order.
  
  This proposal could be extended with an operator for making equivalence accessible beyond use in grouping and `DISTINCT`.
  
  == Benefits to this proposal
  