anchor.diff:  * If either one of LHS or RHS is Date and another isn't, return FALSE
   * LHS eq RHS == TRUE when both LHS and RHS value are numerically identical in Unix Epoch time.
   
  -===== NULL
  -
  -* If either one of LHS or RHS is null and another isn't, return FALSE
  -* If both LHS and RHS are null, return TRUE 
  +===== NULLTYPE
  +
  +* If either one of LHS or RHS is NULLTYPE and another isn't, return FALSE
  +* If both LHS and RHS are NULLTYPE, return TRUE 
   
   ==== Composite types
   
  
positive.code: * Map.Entry is Java dependent type. Instead of defining semantics for Map.Entry, do we introduce a concept of like key-value tuple for it to generalize ?
  * Today we have Date type but don’t we need timezone aware DateTime type as well ?
  * Some graph providers may not support BigDecimal. Do we leave how TP deals with BigDecimal to Graph providers ?
  * Which should be more reasonable, NULL eq NULL is true or false ?
    ** If it is true, it may be respected in JOIN operation
  * There are a number of situations where the Gremlin grammar won’t support some of the examples - to what extent do these sorts of constructs need to exist in the grammar? Not having them would impact the ability to supply tests that enforce the behaviors that we’ve outlined. 
  
  
negative.code: * NaN is not equivalent to any other numbers
      ** NaN *is equivalent to* NaN irrespective to its underlying type, so in Java, for example, Double.NaN is equivalent to Float.NaN.
  
  ===== NULLTYPE
  * NULLTYPE is not equivalent to any other values
  * NULLTYPE is equivalent to NULLTYPE
  
  === Comparability
  
  