That would be really nice for data structures defined in TR and used in
untyped Racket, for which the contract boundary imposes O(n) overhead
for everything. Also, it sounds dangerous. :D
It wouldn't solve the problem entirely, though. Here's an untyped
program that has it:
#lang racket
(mo
I imagine a type-definition construct that allows programmers to specify how
the type is translated into a contract. Think (define-trusted-type Finalizer C)
and then the C specifies how little and how much of the type you wish to check.
And yes, this is potentially a soundness hole but I am th
Can you say more about what the API for what you're imagining is?
Sam
On Sun, Aug 17, 2014 at 3:41 PM, Matthias Felleisen
wrote:
>
> I am imagining that the type compilation of type Finalizer and such things
> would be parameterized over programmer code which would yield a 'trusted'
> 'thing'
I am imagining that the type compilation of type Finalizer and such things
would be parameterized over programmer code which would yield a 'trusted'
'thing' in this case except that this would open the door for other such
things.
On Aug 17, 2014, at 3:39 PM, Sam Tobin-Hochstadt wrote:
> H
How would that change things here? The issue is about
finalizer-for-what, and that chaperones/impersonators affect object
identity.
Sam
On Sun, Aug 17, 2014 at 3:37 PM, Matthias Felleisen
wrote:
>
> Could we benefit from an abstract/opaque Finalizer type here? I know we don't
> have those yet b
Could we benefit from an abstract/opaque Finalizer type here? I know we don't
have those yet but it may address the general problem. -- Matthias
On Aug 16, 2014, at 8:55 AM, Neil Toronto wrote:
> Short version: the contract system doesn't allow `register-finalizer` to be
> used in Typed Rac
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.
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
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:
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
10 matches
Mail list logo
