>> On 09/17/2015 09:27 PM, Robby Findler wrote: > No, you're not learning something, even in that case. Well, I suppose > you might say that you're learning it didn't return #t, but what that > really means is "try harder". I consider check-eq? and friends a > mistake, symbols I've already mentioned and eq hash table are really > just a fancier form of eq? (so if I'm being careful I should include > them).
I looked back at one of my bug reports, and indeed my example was using an immutable object--my bad: #lang typed/racket (require typed/rackunit) (define foo (cons 1 1)) (eq? foo foo) (check-eq? foo foo) But, here is an update: #lang typed/racket (require typed/rackunit) (define foo (mcons 1 1)) (eq? foo foo) (check-eq? foo foo) And this is still broken. > 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. I get that it wants the freedom, I'm just not sure it currently has the freedom. The docs say, "The eq? operator compares two values, returning #t when the values refer to the same object. This form of equality is suitable for comparing objects that support imperative update". If this is no longer true, it implies that weak hash tables are broken (they could arbitrarily drop entries), and that worries me. Secondly, isn't equality the wrong word if a #t result means something and #f doesn't? I suppose the issue is with the phrase "same object". >> As an example, I'm writing a toy sets-of-scopes expander. Scopes could >> be Natural, or whatever, but I'm wrapping them in a struct so I can use >> them to key weak tables. I can see other some other kind of language >> support as a replacement, like an Identity type, or some kind of Graph >> type where nodes not connected to a root are garbage (making local that >> formerly global feature of the heap). > > I think weak tables are a separate issue. You mean eq tables, right? I did mean "make-weak-hash". It is desirable to couple the garbage collection of binding table entries with the garbage collection of scopes. I was using weak hash tables to map scope objects to binding table partitions. mflatt achieves this by storing those partitions directly inside the scope objects, avoiding a weak table. There are costs and benefits of the two options. Anyway, if we are allowed to use weak tables for memory management, then we require a stable notion of identity. I agree that object identity is ugly, so I'd trade it for an efficient, immutable, persistent, graph datatype which allowed nodes to be collected when unreferenced from a root :). -- 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.
