[email protected] wrote:
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.
'==' in JS has always been reference equality for two objects.
The second was that because Racket features pre-emptive concurrency, which JS does not,
Right!
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).
I didn't see a compelling example (the function f(x, y) { return (x === y) ? "something" : y.foo; } example was contrived), but one that wants structural at-this-moment equality of the Racket 'equal?' kind can be written in JS (using an ES6 WeakMap memo to traverse object graphs without cycling forever or visiting multiple connected subgraphs more than once).
The code that wants contracts to be transparent for such an operation will have to provide that operation as a function. In no case do I see JS == or === changing, in ECMA-262 or in an accepted patch to SpiderMonkey.
Andreas, can you not proceed without hacking either one engine or the standard, by writing such a function equalp(x, y) {...} yourself and using it?
/be _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
