On Thu, Sep 17, 2015 at 11:35 PM, Anthony Carrico <[email protected]> wrote: > On 09/17/2015 11:03 PM, Anthony Carrico wrote: >> Really what I'm trying to say is that the language implementation >> wants the freedom to adjust your program without having to be >> constrained by eq tests that you might do. One example of this is >> contracts. I might wish to be accept a function you give me, put a >> contract on it, and give it back to you. This shouldn't really be >> detectable if the contract doesn't fail. But it is, because of eq?. >> Similarly, a compiler might want to change around exactly when it >> allocates those cons cells (doing more sharing sometimes to reduce >> memory footprint) but it can't because this is detectable via eq?, so >> it isn't a behavior preserving transformation. > > Both these examples seem fine. Nobody expects procedures to be > comparable, and cons cells are immutable, so the docs say eq? isn't > suitable anyway (my bug report notwithstanding).
I agree that an interesting other approach is to make eq? have some well-defined behavior for mutable objects that amounts to "if I mutate one, does the other one change". This will, however, mean that eq? is not just a simple pointer equality check in the runtime system (well, unless other changes are made in other parts of the runtime system that I don't know how to do). So I don't think that's the best choice (still making choices between things that are alternative futures for Racket here, not talking about the current set of promises). Robby -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
