Re: [racket-users] intensional equality and unit tests
> On Feb 21, 2017, at 1:01 PM, Gustavo Massaccesi wrote: > > I'm not sure if this changed. To get a #t with equal? you can add > #:transparent . But be careful because #:transparent is more powerful > than what I expected. For example, it makes available the constructor > of the struct. I’m sorry, I should have mentioned that I’m familiar with #:transparent. My memory was that the default inspector associated with a struct-def would allow equal? to inspect the fields within the module; that’s clearly not the case now, if indeed it ever was. Sorry for the noise. John -- 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.
Re: [racket-users] intensional equality and unit tests
I'm not sure if this changed. To get a #t with equal? you can add #:transparent . But be careful because #:transparent is more powerful than what I expected. For example, it makes available the constructor of the struct. #lang racket (define-struct foo (a b)) (make-foo 3 4) ; ==> # (equal? (make-foo 3 4) (make-foo 3 4)) ; ==> #f (define-struct foo/tr (a b) #:transparent) (make-foo/tr 3 4); ==> # (equal? (make-foo/tr 3 4) (make-foo/tr 3 4)) ; ==> #t Gustavo -- 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.
Re: [racket-users] intensional equality and unit tests
> On Feb 20, 2017, at 2:27 PM, Sam Tobin-Hochstadt wrote: > > Maybe that's true, but I haven't wanted to do that in my Racket code > using either `check-expect` in class or `check-equal` in Rackunit (or > at least, not enough to define a new abstraction for it). Have you > tried making a testing framework to accommodate this better? I have wanted this, and have done this, many times. But I will say that it doesn’t come that easy in Racket either. -- 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.
Re: [racket-users] intensional equality and unit tests
On Mon, Feb 20, 2017 at 2:23 PM, 'John Clements' via Racket Users wrote: > >> On Feb 20, 2017, at 11:06, Sam Tobin-Hochstadt wrote: >> >> I don't think `check-expect` is doing something that's >> module-relative. For example, this program: >> >> #lang racket >> (require test-engine/racket-tests) >> (struct x (a)) >> (check-expect (x 1) (x 1)) >> (run-tests) >> (display-results) >> >> fails its test. `equal?` in Racket checks structural equality in a >> deep way, which is indeed a feature not found in Java and Python, but >> I don't think it's any different than overriding .equals() everywhere >> in Java to perform structural traversal. > > I agree; my only point is that those writing unit tests probably want to > define (or have defined) two separate notions of equality; one for use in > tests, and one for use by clients. And that testing frameworks should > accommodate/encourage this. Maybe that's true, but I haven't wanted to do that in my Racket code using either `check-expect` in class or `check-equal` in Rackunit (or at least, not enough to define a new abstraction for it). Have you tried making a testing framework to accommodate this better? Sam > > John > >> >> Sam >> >> On Mon, Feb 20, 2017 at 1:53 PM, 'John Clements' via Racket Users >> wrote: >>> On Feb 19, 2017, at 14:40, Matthias Felleisen wrote: > On Feb 18, 2017, at 11:12 PM, 'John Clements' via Racket Users > 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? John, 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 ar
Re: [racket-users] intensional equality and unit tests
> On Feb 20, 2017, at 11:06, Sam Tobin-Hochstadt wrote: > > I don't think `check-expect` is doing something that's > module-relative. For example, this program: > > #lang racket > (require test-engine/racket-tests) > (struct x (a)) > (check-expect (x 1) (x 1)) > (run-tests) > (display-results) > > fails its test. `equal?` in Racket checks structural equality in a > deep way, which is indeed a feature not found in Java and Python, but > I don't think it's any different than overriding .equals() everywhere > in Java to perform structural traversal. I agree; my only point is that those writing unit tests probably want to define (or have defined) two separate notions of equality; one for use in tests, and one for use by clients. And that testing frameworks should accommodate/encourage this. John > > Sam > > On Mon, Feb 20, 2017 at 1:53 PM, 'John Clements' via Racket Users > wrote: >> >>> On Feb 19, 2017, at 14:40, Matthias Felleisen wrote: >>> >>> On Feb 18, 2017, at 11:12 PM, 'John Clements' via Racket Users 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? >>> >>> >>> John, >>> >>> 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 slots. >>> >>> In any case, I doubt equal? helps you here. Did I misunderstand anything? >> >> No, I don’t think you missed anything, but from the standpoint of those >> teaching early classes in either Java or Python (a standpoint that I >> understand you are generally and mercifully not compelled to adopt), it >> seems that there’s a missing piece in unit testing frameworks: namely, the >> default che
Re: [racket-users] intensional equality and unit tests
> On Feb 20, 2017, at 11:02, Matthias Felleisen wrote: > > >> On Feb 20, 2017, at 1:53 PM, John Clements wrote: >> >> No, I don’t think you missed anything, but from the standpoint of those >> teaching early classes in either Java or Python (a standpoint that I >> understand you are generally and mercifully not compelled to adopt), > > > Yes. As a you know well, I firmly believe that such courses should be taught > with teaching languages that are best suited for beginners. No of-the-rack > language is good enough for the job. One of the things we should show > students is that existing languages are bad (in many different regards). It’s > the second course that should make students chafe against the (low) moral > compromises of existing languages (Java, Python), because we owe them an > introduction to the baddities of the real world. (Is this a bad neologism?) > > In this spirit . . . > > >> it seems that there’s a missing piece in unit testing frameworks: namely, >> the default check-expect form in these languages should not be one that >> refers to the notion of outside-of-module-extensional equality, but rather >> one that refers to inside-of-module-extensional equality, as check-expect >> does. I’d be tempted to call this notion of equality “testing equality,” but >> I’ve been called out before on my barbarous neologisms. (Not sure this one >> would be considered barbarous, at any rate.) Additionally, students should >> probably not be required to implement this notion of equality by hand. >> Sounds like a nice three-page position paper, probably not good enough for >> ITICSE, maybe SIGSCE (sigh). > > > Did Viera Proulx’s testing framework and its reliance on reflection solve the > problem for Java? Given that both languages do come with reflection > capabilities (this makes me want to include #%app and #%module-begin in ISL > so we can discuss good language interposition strategies), the question is > > can you mimic Racket’s approach to inside-testing and > outside-observation? > > Then you can turn your 3-pager into a real paper. Or someone has already done > it. Well, thank you for reminding me of Viera’s framework. Reflection seems like the Wrong Way to implement this, if you have the option of using macros. Are Java’s macros still not up to this task? Also, when you refer to Racket’s approach to inside-testing and outside-observation, are you referring to the combination of equal? and the ability to provide an externally-visible equality relation? Or are you referring to inspectors? Related: I feel as though five years ago, this code evaluated to #t: (define-struct foo (a b)) (equal? (make-foo 3 4) (make-foo 3 4)) … which, I suppose, only goes to show that I don’t understand Racket’s notion of equality well either. John > > -- > 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.
Re: [racket-users] intensional equality and unit tests
I don't think `check-expect` is doing something that's module-relative. For example, this program: #lang racket (require test-engine/racket-tests) (struct x (a)) (check-expect (x 1) (x 1)) (run-tests) (display-results) fails its test. `equal?` in Racket checks structural equality in a deep way, which is indeed a feature not found in Java and Python, but I don't think it's any different than overriding .equals() everywhere in Java to perform structural traversal. Sam On Mon, Feb 20, 2017 at 1:53 PM, 'John Clements' via Racket Users wrote: > >> On Feb 19, 2017, at 14:40, Matthias Felleisen wrote: >> >> >>> On Feb 18, 2017, at 11:12 PM, 'John Clements' via Racket Users >>> 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? >> >> >> John, >> >> 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 slots. >> >> In any case, I doubt equal? helps you here. Did I misunderstand anything? > > No, I don’t think you missed anything, but from the standpoint of those > teaching early classes in either Java or Python (a standpoint that I > understand you are generally and mercifully not compelled to adopt), it seems > that there’s a missing piece in unit testing frameworks: namely, the default > check-expect form in these languages should not be one that refers to the > notion of outside-of-module-extensional equality, but rather one that refers > to inside-of-module-extensional equality, as check-expect does. I’d be > tempted to call this notion of equality “testing equality,” but I’ve been > called out before on my barbarous neologisms. (Not sure this one would be > considered barbarous, at any rate.) Additionally, students should probably > not be require
Re: [racket-users] intensional equality and unit tests
> On Feb 20, 2017, at 1:53 PM, John Clements wrote: > > No, I don’t think you missed anything, but from the standpoint of those > teaching early classes in either Java or Python (a standpoint that I > understand you are generally and mercifully not compelled to adopt), Yes. As a you know well, I firmly believe that such courses should be taught with teaching languages that are best suited for beginners. No of-the-rack language is good enough for the job. One of the things we should show students is that existing languages are bad (in many different regards). It’s the second course that should make students chafe against the (low) moral compromises of existing languages (Java, Python), because we owe them an introduction to the baddities of the real world. (Is this a bad neologism?) In this spirit . . . > it seems that there’s a missing piece in unit testing frameworks: namely, the > default check-expect form in these languages should not be one that refers to > the notion of outside-of-module-extensional equality, but rather one that > refers to inside-of-module-extensional equality, as check-expect does. I’d be > tempted to call this notion of equality “testing equality,” but I’ve been > called out before on my barbarous neologisms. (Not sure this one would be > considered barbarous, at any rate.) Additionally, students should probably > not be required to implement this notion of equality by hand. Sounds like a > nice three-page position paper, probably not good enough for ITICSE, maybe > SIGSCE (sigh). Did Viera Proulx’s testing framework and its reliance on reflection solve the problem for Java? Given that both languages do come with reflection capabilities (this makes me want to include #%app and #%module-begin in ISL so we can discuss good language interposition strategies), the question is can you mimic Racket’s approach to inside-testing and outside-observation? Then you can turn your 3-pager into a real paper. Or someone has already done it. -- 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.
Re: [racket-users] intensional equality and unit tests
> On Feb 19, 2017, at 14:40, Matthias Felleisen wrote: > > >> On Feb 18, 2017, at 11:12 PM, 'John Clements' via Racket Users >> 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? > > > John, > > 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 > slots. > > In any case, I doubt equal? helps you here. Did I misunderstand anything? No, I don’t think you missed anything, but from the standpoint of those teaching early classes in either Java or Python (a standpoint that I understand you are generally and mercifully not compelled to adopt), it seems that there’s a missing piece in unit testing frameworks: namely, the default check-expect form in these languages should not be one that refers to the notion of outside-of-module-extensional equality, but rather one that refers to inside-of-module-extensional equality, as check-expect does. I’d be tempted to call this notion of equality “testing equality,” but I’ve been called out before on my barbarous neologisms. (Not sure this one would be considered barbarous, at any rate.) Additionally, students should probably not be required to implement this notion of equality by hand. Sounds like a nice three-page position paper, probably not good enough for ITICSE, maybe SIGSCE (sigh). John -- 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.
Re: [racket-users] intensional equality and unit tests
> On Feb 18, 2017, at 11:12 PM, 'John Clements' via Racket Users > 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? John, 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 slots. 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.
Re: [racket-users] intensional equality and unit tests
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.
[racket-users] intensional equality and unit tests
(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 -- 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.
