I can't think of a case where strongly holding values is useful. Avoiding a layer of ephemerons is less work for the GC, and so `make-weak-hash` omits it to provide better performance for cases that don't need it. I'm not sure how much of a space and performance difference it makes in modern Racket, though; ephemeron performance is much better than it was originally. So, it could be worth taking measurements and revisiting that choice.
Meanwhile, the reference docs for `make-weak-hash` should be more helpful, and I'll adjust the docs. At Wed, 21 Oct 2015 22:03:09 -0400, Scott Moore wrote: > Thanks for the quick response! > > Now that I’m past that, I see that my problem is probably due to the fact > that > a weak-hash holds its key strongly. Turns out this is well-documented in the > guide, but I missed it since I was reading the reference. > > I’m curious, is there a particular use case for the fact that a weak-hash > doesn’t act more like a collection of ephemerons? The guide notes that the > strong reference to the value "creates a catch-22 dependency when a value > refers back to its key, so that the mapping is retained permanently.” But > worse than that, the cycle can be through a second mapping: > > > (define ht (make-weak-hasheq)) > > (let ([a (gensym)] > > [b (gensym)]) > > (hash-set! ht a b) > > (hash-set! ht b a)) > > (collect-garbage) > > (hash-count ht) > 2 > On October 21, 2015 at 9:19:05 PM, Matthew Flatt (mfl...@cs.utah.edu) wrote: > > An empty closure is allocated as a constant --- similar to a literal > string or literal fraction in your program. The "closure" will stick > around as long as the code does, and the code will stick around as the > namespace where its loaded. > > If you change `(λ () 0`) to `(λ () (if box 0 'huh?))`, then you end up > with a non-empty closure (i.e., allocated at run time) due to the > reference to `box`, and so you get `#f` at the end as you expect. > > I don't know why PasteRack produces #f, but it must not hold onto the > namespace. > > At Wed, 21 Oct 2015 21:07:52 -0400, Scott Moore wrote: > > I’m trying to do something a bit fancy that makes use of weak-hashes, but > I’ve > > run into strange behavior (things not being removed that I believe should > be) > > when I use keys that are closures. Doing some of my own debugging, this > > doesn’t appear specific to weak hashes, but also to weak boxes. Here is a > > short example (based on the example programs in section 19.11 of > > http://docs.racket-lang.org/guide/performance.html): > > > > #lang racket > > > > (struct foo ()) > > > > (define box #f) > > > > (let ([f (foo)]) > > (set! box (make-weak-box f)) > > (weak-box-value box)) > > (weak-box-value box) > > (collect-garbage) > > (weak-box-value box) > > > > (let ([f (λ () 0)]) > > (set! box (make-weak-box f)) > > (weak-box-value box)) > > (weak-box-value box) > > (collect-garbage) > > (weak-box-value box) > > > > I expect the output of this program to be: > > > > #<foo> > > #<foo> > > #f > > #<procedure:f> > > #<procedure:f> > > #f > > > > Curiously, I do get this answer if I paste the program to pasterack.org. If > > > > instead I run the program in DrRacket, or at the command line (both > compiled > > and not compiled), I get this output: > > > > #<foo> > > #<foo> > > #f > > #<procedure:f> > > #<procedure:f> > > #<procedure:f> > > > > Any idea what is happening here? As far as I can tell, the reachability of > “f” > > in both code blocks should be identical, despite the difference in the type > of > > value. Maybe some sort of compiler transformation or a subtlety in the > > reachability analysis? Or a bug? > > > > Thanks, > > Scott > > > > -- > > 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. > > -- > 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. > > -- > 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. -- 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.
