[racket-dev] Testing whether a procedure gets collected

On 12/02/2012 12:10 PM, Robby Findler wrote:
> On Sun, Dec 2, 2012 at 11:43 AM, Matthias Felleisen
> <matthias at ccs.neu.edu> wrote:
>>
>> On Dec 1, 2012, at 9:23 PM, Robby Findler wrote:
>>
>>> I think the high-level answer is that you have to understand something
>>> about details that aren't currently specified but nevertheless are how
>>> things currently work and then make a test that will work when you
>>> make those additional assumptions (and then keep it running in drdr so
>>> you can tell when the assumptions get broken).
>>
>>
>> Doesn't this suggest deep down that Neil is trying to 'beat'
>> Racket and its implementation with his program? I think the
>> entire discussion (I didn't follow every detail) points to
>> something lacking about the language. -- Matthias
>
> I think that Neil wants to formulate a test case that checks that his
> datastructure doesn't leak and is complaining about the lack of
> specification for what "If the garbage collector has proven" (quote
> from the docs) means.

I didn't mean to sound complain-y... :p

> My experience with similar testing is that the level of specification
> is actually okay. I can't speak for finalizers (they are more complex)
> but weak boxes seem fine.

And that helps a lot, so thanks!

You're both right, of course. I'm essentially trying to test something 
that is unobservable. The fact that I can observe it is an 
implementation accident. The specific accident, that a weak box is 
cleared as soon as possible, happens to be common and generally expected.

I don't know whether it's worth it in this case to tighten the 
specification. I don't want anyone to spend time on it unless it's 
actually worth researching.

Neil ⊥