On Sun, Dec 2, 2012 at 11:40 PM, Neil Toronto <neil.toro...@gmail.com> wrote: > On 12/02/2012 12:10 PM, Robby Findler wrote: >> >> On Sun, Dec 2, 2012 at 11:43 AM, Matthias Felleisen >> <matth...@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
Oh no. "complain" here was not meant to be a negative. Sorry. You "expressed dissatisfaction" and I think it is reasonable to do so. >> 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. I don't know that there is a paper to be found, but I agree that an informal description that explains a little more about when one can intuitively expect a weak box to be cleared seems useful. I agree that when something is collected is a pretty intentional property but I think it is possible to say a little bit more since there is a pretty stable core idea there (namely that if something isn't reachable and you call collect-garbage you can be pretty sure it'll be gone -- this was not the case back in the boehm gc days). Hm. I'll think more about this and see if I can improve the docs. Robby _________________________ Racket Developers list: http://lists.racket-lang.org/dev