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). -- Anthony Carrico -- 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.
