pasterack uses make-module-evaluator in a sandbox. It's also still
running 6.1.1. Would either of those cause the observed difference?

On Wed, Oct 21, 2015 at 9:18 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.

Reply via email to