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
6 matches
Mail list logo
