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
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
matth...@ccs.neu.edu wrote:
Could we benefit from an abstract/opaque Finalizer type here? I know we don't
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
matth...@ccs.neu.edu wrote:
I am imagining that the type compilation of type Finalizer and such things
would be parameterized over programmer code which would yield a
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
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
5 matches
Mail list logo
