anchor.diff:  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).
  +The concept of equality is used by the equality operator `=`, the inequality operator `<>`, value joins, and the `IN` operator.
  +The concept of equivalence is used by the `DISTINCT` clause modifier and in 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 potentially filtering out more rows when used in a predicate.
   
   === 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.
  +This proposal could be extended with an operator for making equivalence accessible beyond use in grouping and `DISTINCT`.
   
   == Benefits to this proposal
   
  -A consistent set of rules for equality, comparability and orderability.
  +A consistent set of rules for equality, equivalence, 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
  +=== Appendix: Comparability by Type
   
  -Put any supplementary information here.
  +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
  +[frame="topbot",options="header,footer"]
  +|===========================================================================================================================================
  +|Type           | `NODE` | `RELATIONSHIP` | `PATH` | `MAP` | `LIST OF ANY?` | `STRING` | `BOOLEAN` | `NUMBER` | `INTEGER` | `FLOAT` | `VOID`
  +|`NODE`         | X      |                |        |       |                |          |           |          |           |         |
  +|`RELATIONSHIP` |        | X              |        |       |                |          |           |          |           |         |
  +|`PATH`         |        |                | X      |       |                |          |           |          |           |         |
  +|`MAP`          |        |                |        | X     |                |          |           |          |           |         |
  +|`LIST OF ANY?` |        |                |        |       | X              |          |           |          |           |         |
  +|`STRING`       |        |                |        |       |                | X        |           |          |           |         |
  +|`BOOLEAN`      |        |                |        |       |                |          | X         |          |           |         |
  +|`NUMBER`       |        |                |        |       |                |          |           | X        | X         | X       |
  +|`INTEGER`      |        |                |        |       |                |          |           | X        | X         | X       |
  +|`FLOAT`        |        |                |        |       |                |          |           | X        | X         | X       |
  +|`VOID`         |        |                |        |       |                |          |           |          |           |         |
  +|===========================================================================================================================================
  +`
  
positive.code: [source, cypher]
  ----
  UNWIND [[null], [null]] AS i
  RETURN DISTINCT i // should return two rows
  ----
  
  === Semantics
  
  //Provide a description of the expected semantics of the new feature(s).
  //Use subheadings to structure the content.
  //
  //_Examples are shown below in sections 3.3.1–3.3.3:_
  
  === Interaction with existing features
  
  
negative.code: 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, ...]
  <=>
  