+ Because of the particular way the numerical identity predicates are implemented in all of these languages, it doesn't quite match our conceptual expectations. For instance, For instance, if `ycell` is a reference cell, then `ref !ycell` will always be a numerically distinct reference cell containing the same value. We get this pattern of comparisons in OCaml:
+
+ ycell == ycell
+ ycell != ref !ycell (* true, these aren't numerically identical *)
+
+ ycell = ycell
+ ycell = ref !ycell (* true, they are qualitatively indiscernible *)
+
+ But now what about?
+
+ (0, 1, ycell) ? (0, 1, ycell)
+ (0, 1. ycell) ? (0, 1. ref !ycell)
+
+ You might expect the first pair to be numerically identical too---after all, they involve the same structure (an immutable triple) each of whose components is numerically identical. But OCaml's "physical identity" predicate `==` does not detect that identity. It counts both of these comparisons as false. OCaml's `=` predicate does count the first pair as equal, but only because it's insensitive to numerical identity; it also counts the second pair as equal. This shows up in all the other languages I know, as well. In Python, `y = []; (0, 1, y) is (0, 1, y)` evaluates to false. In Racket, `(define y (box 1)) (eq? (cons 0 y) (cons 0 y))` also evaluates to false (and in Racket, unlike traditional Schemes, `cons` is creating immutable pairs). They chose an implementation for their numerical identity predicates that is especially efficient and does the right thing in the common cases, but doesn't quite match our mathematical expectations.
+
+ Additionally, note that none of the equality predicates so far considered is the same as the "hyperequals" predicate mentioned above. For example, in the following (fictional) language: