From a07a7e1719e637449177695d4f703d656b8e5ccb Mon Sep 17 00:00:00 2001
From: Jim Pryor
Date: Tue, 23 Nov 2010 08:33:34 -0500
Subject: [PATCH] week9 tweak =/==
Signed-off-by: Jim Pryor
---
week9.mdwn | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/week9.mdwn b/week9.mdwn
index 63929830..a7385249 100644
--- a/week9.mdwn
+++ b/week9.mdwn
@@ -625,20 +625,20 @@ Programming languages tend to provide a bunch of mutation-related capabilities a
Terminological note: in OCaml, `=` and `<>` express the qualitative (in)discernibility relations, also expressed in Scheme with `equal?`. In OCaml, `==` and `!=` express the numerical (non)identity relations, also expressed in Scheme with `eq?`. `=` also has other syntactic roles in OCaml, such as in the form `let x = value in ...`. In other languages, like C and Python, `=` is commonly used just for assignment (of either of the sorts we've now seen: `let x = value in ...` or `change x to value in ...`). The symbols `==` and `!=` are commonly used to express qualitative (in)discernibility in these languages. Python expresses numerical (non)identity with `is` and `is not`. What an unattractive mess. Don't get me started on Haskell (qualitative discernibility is `/=`) and Lua (physical (non)identity is `==` and `~=`).
- The `=` and `==` predicates in OCaml do not between them cover all the natural cases you may want to test for. 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:
+ 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
+ ycell != ref !ycell (* these aren't numerically identical *)
ycell = ycell
- ycell = ref !ycell
+ ycell = ref !ycell (* they are qualitatively indiscernible *)
But now what about?
(0, 1, ycell) ? (0, 1, ycell)
(0, 1. ycell) ? (0, 1. ref !ycell)
- You might expect that there'd be an equality predicate that counts the first pair as equal, but not the second. But there isn't. OCaml's physical identity predicate `==` counts each pair as non-equal, even though the first of them involves the same structure containing only physically identical components. OCaml's structural equality preficate `=` counts both pairs as equal; it's insensitive to the lack of physical identity between `ycell` and `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:
--
2.11.0