Re: [racket-dev] A tricky chaperone puzzle

2014-07-25 Thread Sam Tobin-Hochstadt
I only thought of it because the first thing I tried was to break the chaperone invariant, thinking that 2 might already have been the behavior. I only came up with the access control variant when that didn't work. Sam On Jul 25, 2014 6:04 AM, "Matthew Flatt" wrote: > Unless I still have it wron

Re: [racket-dev] A tricky chaperone puzzle

2014-07-25 Thread Matthew Flatt
Unless I still have it wrong, the implementation of 2 was straightforward. I would have overlooked the need to restrict `chaperone-struct` to chaperones of accessors and mutators if you hadn't mentioned it. At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote: > Consider the following mo

Re: [racket-dev] A tricky chaperone puzzle

2014-07-24 Thread Robby Findler
Yes, true! Robby On Thu, Jul 24, 2014 at 8:07 PM, Sam Tobin-Hochstadt wrote: > Struct chaperones are the important part, I think. > > But the theorem would be false under option 1, I think. Adding contracts can > add non-contract errors -- the error you get when a you supply the wrong > accessor

Re: [racket-dev] A tricky chaperone puzzle

2014-07-24 Thread Sam Tobin-Hochstadt
Struct chaperones are the important part, I think. But the theorem would be false under option 1, I think. Adding contracts can add non-contract errors -- the error you get when a you supply the wrong accessor for struct-chaperone. Sam On Jul 24, 2014 7:54 PM, "Robby Findler" wrote: > Ah, nope.

Re: [racket-dev] A tricky chaperone puzzle

2014-07-24 Thread Robby Findler
Ah, nope. That model doesn't include function chaperones! Robby On Thu, Jul 24, 2014 at 6:14 PM, Robby Findler wrote: > I also lean towards #2. What does the redex model say? Most of those > pieces are in it, I think. > > Robby > > On Thu, Jul 24, 2014 at 3:25 PM, Matthew Flatt wrote: >> Nice e

Re: [racket-dev] A tricky chaperone puzzle

2014-07-24 Thread Robby Findler
I also lean towards #2. What does the redex model say? Most of those pieces are in it, I think. Robby On Thu, Jul 24, 2014 at 3:25 PM, Matthew Flatt wrote: > Nice example. Offhand, I think that #2 is right, but I'll have to look > at it more to be sure. > > At Thu, 24 Jul 2014 15:45:18 -0400, Sa

Re: [racket-dev] A tricky chaperone puzzle

2014-07-24 Thread Sam Tobin-Hochstadt
Thinking about it more, I think it has to be #2, since otherwise: (module m1 racket (struct x (a)) (provide (contract-out (struct x ([a integer?] (module m2 racket (require 'm1) (provide (contract-out (struct x ([a even?] won't work, which seems like something that should be supp

Re: [racket-dev] A tricky chaperone puzzle

2014-07-24 Thread Matthew Flatt
Nice example. Offhand, I think that #2 is right, but I'll have to look at it more to be sure. At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote: > Consider the following module: > > (module m racket > (struct x [a]) > (define v1 (x 'secret)) > (define v2 (x 'public)) > (provid

[racket-dev] A tricky chaperone puzzle

2014-07-24 Thread Sam Tobin-Hochstadt
Consider the following module: (module m racket (struct x [a]) (define v1 (x 'secret)) (define v2 (x 'public)) (provide v1 v2) (provide/contract [x-a (-> x? (not/c 'secret))])) It appears that this ensures that you can't get 'secret. But, it turns out that I can write a function outside