> On Feb 18, 2017, at 11:12 PM, 'John Clements' via Racket Users 
> <racket-users@googlegroups.com> wrote:
> (cc:ak)
> Okay, this sounds just crushingly obvious now that I say it, but honestly, I 
> don’t think it’s occurred to me: 
> One reason that equality is such a nightmare in Java and Python (which turns 
> out to be JUST AS BAD), is that those of us that actually want to write unit 
> test cases want *intensional* equality, not extensional equality—but not 
> pointer-based equality.
> I just came across a nice example while working on code for first-year 
> students (thanks, Aaron!).
> Specifically, imagine an “array” class that contains a backing array and a 
> length, where the backing array might be arbitrarily longer than the length:
> (struct arr (vec len))
> So, for instance, an array with two elements in it might be represented as 
> either
> (arr (vector “apple" “horse” #f #f #f) 2)
> or as
> (arr (vector “apple” “horse” #f) 2)
> —they both represent the array of length 2 that has “apple” as the first 
> element, and “horse” as the second.
> If I’m providing this library to be used by others, I probably want 
> extensional equality; I don’t want users of my library to be able to 
> distinguish between the two. However, if I’m writing unit tests for my 
> library, I definitely *do* want to be able to distinguish between the two, 
> for instance in checking the behavior of arrays that fill up and need to be 
> resized. Moreover, pointer-based equality—the == of Java, and the `is` of 
> Python (IIUC)—is also largely useless for unit tests.
> It’s probably not terribly controversial to suggest that neither Python nor 
> Java were designed with unit testing in mind. Accordingly, I shouldn’t be 
> surprised to discover that they don’t provide a natural notion of equality 
> that fits well with unit tests.
> So, I have three questions:
> 1) Is there an existing term for what I would call “functional extensional 
> equality”—that is, Racket’s ‘equal?’ ?
> 2) Does what I wrote make sense?
> 3) Has this been written down somewhere else, as part of a larger work?


what you point out is that extensional equality depends on the point of view. 
In your specific example, ‘arr’ from inside the module — specifically for 
non-exported functions — equal? must take into account the full vector. For a 
client module, equality is a notion of projection (elimination of array 
fields). In particular, I would expect your module to declare the structure 
opaque so that equal? does not inspect the full array. Additionally, I would 
expect you to export a function called arr-equal? so that clients can determine 
whether two instances are extensionally equal from their perspective (which is 
apparently needed in your context). 

If you were in a typed functional world, I’d use a sealed structure for the 
module or at least an existential type so that the outside world cannot inspect 
arr’s vec filed. This shows that equality is a type-dependent notion — just as 
Reynolds said it. 

In a typed OO world such as Java, you’d override .equal, which is public and 
thus accessible. But for internal, private comparisons, you’d have to step 
outside of Java’s equality predicate and use a method that inspects the full 
vec field. Here this is relatively easy because you are dealing with just two 

In any case, I doubt equal? helps you here. Did I misunderstand anything? 

— Matthias

You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to