On Sat, 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? > > Thanks, everyone! > > John > I think this relates to the concept of duck typing ( https://en.wikipedia.org/wiki/Duck_typing) -- if something is fit for purpose then it is good enough even if it isn't precisely the same. That's pretty much what 'equal?' is -- "Are these two things similar enough that I could interchange them without screwing up my code?" I'm not aware of any papers on the subject, but I would probably check some of the unit testing books. I've seen the argument that unit tests actually show a weakness in a language, that it's preferable to have declarative semantics. This is one place where Racket's contracts really shine. Suppose I write this: (define/contract (foo a b) (-> string? number? integer?) ... ) There are entire swaths of unit tests I don't need to write, such as "what happens if I pass an integer in the first slot", etc. I *know* what happens -- it throws an exn:fail:contract of a very precisely specified form. I haven't looked into Typed Racket yet, but I gather it will deal with many similar issues. One thing that I do wish Racket had was better exception handling. Right now I can test if an exception is of a particular type (which tells me the broad class of issue) but if I want to know the specifics I need to regex on the message string. This could be significantly helped by using more precise exception types for various functions. For example, in the db module this: (query-db db-handle "jlasdjfl") throws an exn:fail:sql instead of something like exn:fail:sql:syntax. I've started creating more and more specific exception types for my own code as part of this. > > -- > 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. > -- 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.
