5 ms·
The problem with equality and dynamic typing is rather deep and intractable. Kent Pitman (of Lisp fame) has an entire essay about it: https://www.nhplace.com/ke
by deckard1 5y ago
The problem with equality and dynamic typing is rather deep and intractable. Kent Pitman (of Lisp fame) has an entire essay about it: https://www.nhplace.com/kent/PS/EQUAL.html https://www.nhplace.com/kent/PS/EQUAL.html
> If COPY can't be done properly, then neither can EQUAL. And, in fact, that's the case. There is no uniquely determined equality function for complex structures--there are only arbitrary ones.
What Steele says about equality is true for Scheme. Everyone has seen the famous "Wat" video of adding "{} + {}" in Ruby or JS. But no one ever mentions Scheme or Lisp:
scheme@(guile-user)> (eq? "test" "test")
$1 = #t
scheme@(guile-user)> (eqv? "test" "test")
$2 = #t
scheme@(guile-user)> (define x "test")
scheme@(guile-user)> (define y "test")
scheme@(guile-user)> (eq? x y)
$3 = #f
scheme@(guile-user)> (eqv? x y)
$4 = #f
Of course, if you read the RxRS specs then it's all documented and to be expected. But the same is true for JavaScript. As much as I hate typing the "===", there is precedence.
> breaks an important mathematical property
Even mathematicians get lazy and create new syntax and short cuts to express their ideas. Programming is ultimately a human UI. It's easy to see why automatic type coercion was once popular (and probably will be again, I can almost guarantee this).
- tialaramex 5y agoI was surprised that I was OK with that fact that in Rust a vector and an array with the same elements compare equal. It felt completely reasonable, and I definitely didn't feel that way about it in some other languages where that's true.
- bsder 5y agoErm, no, that doesn't work. I created a quick check in the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=473a0c6db6ca709a11dd501e38f3f0dc https://play.rust-lang.org/?version=stable&mode=debug&editio... Do you have some more context? I suspect somehow things are getting coerced to slices and then compared.
- Measter 5y agoThe implementation isn't symmetric, it'll work if you compare `b == a`. Apparently[0] it's something to do with avoiding code bloat. [0] https://github.com/rust-lang/rust/blob/e4c23daeb461ac02413eb36c8cefcc5530638a05/library/alloc/src/vec/partial_eq.rs#L39 https://github.com/rust-lang/rust/blob/e4c23daeb461ac02413eb...
- fee1-dead 5y agoI suppose the reason is Vec<T> implements `Borrow<[T]>` and [T; N] implements Borrow<[T]> as well. The trait implementation requires these types to have same implementations for all traits including comparisons and hashing. Returning `false` when types don't match doesn't make sense in Rust since Rust is strongly typed (and not interpreted). And say if we don't make them compare equal. then vec![1, 2] != [1, 2] but &vec![1, 2] == &[1, 2], which is just too opaque and confusing. This behavior is no fit for a language like Rust.
- deleted 5y ago[deleted]
- filoeleven 5y agoThis does work in Clojure. Edit: and Clojurescript, which is more relevant. (let [x “test” y “test”] (= x y)) ; returns true with both (let) and individual (def) https://clojure.org/guides/equality https://clojure.org/guides/equality