On Thu, Sep 17, 2015 at 11:35 PM, Anthony Carrico <acarr...@memebeam.org> 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
