Re: [racket-dev] Should `register-finalizer` unwrap impersonators?

2014-08-16 Thread Neil Toronto
That's what I think. The more contracted our values get in Racket programs, the less we can trust `register-finalizer` if it doesn't change. Currently, `register-finalizer` tends to be used right after allocation, when objects don't usually have contracts yet. It doesn't have to be, though.

Re: [racket-dev] Should `register-finalizer` unwrap impersonators?

2014-08-16 Thread Sam Tobin-Hochstadt
That's clearly the right solution for this particular bug, but it does seem like there's a more general problem here. Sam On Sat, Aug 16, 2014 at 10:40 AM, Robby Findler wrote: > Seems simplest to be to have typed racket know to trust register finalizer > and thus avoid wrapping it with a contra

Re: [racket-dev] Should `register-finalizer` unwrap impersonators?

2014-08-16 Thread Robby Findler
Seems simplest to be to have typed racket know to trust register finalizer and thus avoid wrapping it with a contract. Robby On Saturday, August 16, 2014, Neil Toronto wrote: > Short version: the contract system doesn't allow `register-finalizer` to > be used in Typed Racket. > > Long version:

[racket-dev] Should `register-finalizer` unwrap impersonators?

2014-08-16 Thread Neil Toronto
Short version: the contract system doesn't allow `register-finalizer` to be used in Typed Racket. Long version: consider the following Typed Racket program, in which instances of `os-resource-wrapper` represent an operating system resource `os-resource`, which itself is just a counter. It atte