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
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 ⊥
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
