anchor.diff:  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 seen as the same
  +- 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 nulls follow the same difference as the null values themselves.
  +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.
  +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.
  -- Strings are compared in dictionary order.
  -- Lists are compared in dictionary order. List elements are compared pairwise in order.
  -- Booleans, maps, nodes, relationships, and paths are incomparable both within types and between types.
  -- Any other combination of values of different types would yield `null`.
  +- 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`; ie always defined.
  -To accomplish this, there must be a pre-determined type order, and we propose the following order, ascending:
  +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:
   
  -- null
  -- paths
  -- relationships
  -- nodes
  -- maps
  -- lists
  -- strings
  -- booleans
  -- numbers
  -- `NaN`
  +- `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 for the types were comparability is defined (numbers, strings, lists).
  -- The order for nodes and relationships is undefined, and an implementation may choose a global sort order for these freely.
  -- The order for paths is that of a list of nodes and relationships.
  -- The order for maps is that of a list of lists, where the inner lists are the key-value pair of the maps, ordered in ascending sort order for the keys.
  +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.
  -We propose a simple rule, like so
  +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, ...]
   <=>
  
positive.code: The concept of comparability is used by the comparisons operators `<`, `>`, `<=`, >=`.
  
  One major goal of our proposal is for equality semantics to align well with comparability.
  The concept of equality is used by the equality operator `=`, the inequality operator `<>`, `DISTINCT`, value joins, and grouping.
  With the proposals made in this CIP, specifically changing equality for lists, the mentioned functionality is going to treat lists containing `null` as unequal, thus producing more rows (in general).
  
  === Alternatives
  
  This proposal could be extended to define comparability for maps, booleans, and graph types.
  
  This proposal could be extended with a new way to express current grouping semantics (structural equivalence).
  
  - DISTINCT ~ foo, ~ bar
  - lhs ~ rhs
  - ~ expr IN list
  
  == What others do
  
  If applicable, include a feature comparison table, along with any useful links.
  
  To provide a well-rounded comparison, please ensure the inclusion of at least one SQL-based implementation -- such as DB2 or Postgres -- as well as SPARQL.
  If you require any assistance or pointers to the latter, please contact petra.selmer@neotechnology.com.
  
  == Benefits to this proposal
  
  A consistent set of rules for equality, comparability and orderability.
  
  == 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.
  
  == Appendix
  
  Put any supplementary information here.
  
negative.code: [abstract]
  .Abstract
  --
  This CIP intends to introduce and formalise two new concepts, *orderability* and *comparability*, and defines their relationship to the already existing concepts of *equality* and *equivalence*.
  Orderability revolves around the `ORDER BY` clause, and defines the semantics it needs to be able to properly sort values passed to it.
  Comparability revolves around the inequality operators (`>`, `<`, `>=`, `<=`), and defines the semantics they need to properly determine how two values compare to each other.
  In order to get a consistent set of rules, we are proposing some changes to how Cypher defines these concepts.
  --
  
  toc::[]
  