On Tuesday, December 3, 2013 4:52:24 PM UTC-5, Andreas Schlegel wrote: > Why do we want proxies to be transparent with respect to equality in this > case? > > A typical use of contracts is to gradually add contracts to a program while a > programmer > > gains understanding of the program. In this process, it is crucial that the > contract- > > respecting behavior of the program does not change. In particular, equality > should not > > be affected by inserting contracts. (For similar reasons, Racket's proxies - > called > > chaperones and impersonators - are transparent. see [1[)
This isn't quite right about Racket. In Racket, there are two equality operators [1]. `eq?` is like `===` -- it implements pointer equality on objects. It is not transparent to Racket's proxy facilities. `equal?`, by contrast, performs _structural_ equality on most aggregate data types, including lists, hash tables, vectors, sets, etc, and it's overrideable on user-defined data types. `equal?` is also transparent to proxies, even when those proxies change behavior arbitrarily, as in Tom's example. There are two important differences between Racket's design and the JS design. One is that Racket started with two notions of equality, one of which was _not_ pointer equality. Perhaps `==` could fill this role for proxies, but I highly doubt it. The second was that because Racket features pre-emptive concurrency, which JS does not, some of the invariants that you'd lose by having two `equal?` data structures behave differently are already lost (in the case of mutable data). The fact that proxying breaks `eq?`-level equality in Racket has been the source of bugs in real programs, but not very many. Sam Tobin-Hochstadt [1] Really, there are 3, but the third one is irrelevant here. _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
