On Thu, Sep 17, 2015 at 11:24 PM, Anthony Carrico <acarr...@memebeam.org> wrote: > 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.
This might be a bug. I'll defer to the TR maintainers on that. >> 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. I believe it currently does not have that freedom. My messages were meant to describe how I think eq? should be treated. The docs provide stronger guarantees which, as you discovering, we don't quite live up to. In particular, we don't currently have all of the implementation technology we need to properly deny it that freedom. (Which sounds strange, but we are balancing a lot of things here, and one of the is TR's soundness, which currently has higher priority.) > 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. I think this sentence is dodgy. It doesn't actually give you any guarantees. The guarantee that you want is probably more of the form "if there is only a single allocation point for a given object then eq? should return #t when given it as both arguments" with some kind of suitable definition of "allocation point" that doesn't include flowing across a TR boundary. That's not precise either, but is probably heading in the right direction. > Secondly, isn't equality the wrong word if a #t result means something > and #f doesn't? This is the direction I would like to think about for eq?. That is, I see eq? as having value for performance reasons, but for no other reason. So, when you do an eq? test, you should always be shortcircuiting some more complex computation. If you get a #f back, then you are obligated to take the long way 'round, but if you get #t, then you "learned something" that lets you avoid more computation. And in an effort to be more clear: this is not currently what's promised by Racket. This is more what I think we should try out and see if we can make work. >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 :). That would be cool! 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.
