Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-24 Thread Robby Findler 
One approach would be to not expect the clients to use deserialize
directly but provide a thin wrapper module which would be the place to
hang the blame information (and it would use `contract-out`).

Robby


On Mon, Jul 24, 2017 at 1:32 PM, Matthew Flatt  wrote:
> At Mon, 24 Jul 2017 12:35:51 -0500, Philip McGrath wrote:
>> I've also tried putting the
>> definition of `deserialize-info:adder-v0` in a different module, so that
>> its version of `adder` has a contract, but then the binding isn't seen by
>> `make-serialize-info`.
>
> In case you still want to pursue that direction, you can use the pair
> form of the second argument to `make-serialize-info`, which pairs a
> symbol with a reference to an exporting module. See the example below.
>
> (I think there's probably a library that's better to use than a raw
> `variable-reference->module-path-index` plus `module-path-index-join`,
> but I forget.)
>
> I don't see a way to blame the module that calls `deserialize`.
>
> 
>
> #lang racket
>
> (module server racket
>   (require racket/serialize)
>   (provide (contract-out
> [adder (-> natural-number/c (-> natural-number/c
> natural-number/c))]))
>   (struct adder (base)
> #:property prop:procedure
> (λ (this x)
>   (+ (adder-base this) x))
> #:property prop:serializable
> (make-serialize-info (λ (this) (vector (adder-base this)))
>  (cons 'deserialize-info:adder-v0
>(module-path-index-join
> '(submod "." deserialize-info)
> (variable-reference->module-path-index
>  (#%variable-reference
>  #f
>  (or (current-load-relative-directory)
>  (current-directory
>   (define/contract make-adder
> (-> natural-number/c (-> natural-number/c
>  natural-number/c))
> adder)
>
>   (module* deserialize-info racket/base
> (require (submod ".."))
> (require racket/serialize)
> (provide deserialize-info:adder-v0)
> (define deserialize-info:adder-v0
>   (make-deserialize-info adder
>  (λ () (error 'adder
>   "can't have cycles"))
>
>
> (require 'server racket/serialize)
>
> ((deserialize (serialize (adder 5))) 'not-a-number)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-24 Thread Matthew Flatt 
At Mon, 24 Jul 2017 12:35:51 -0500, Philip McGrath wrote:
> I've also tried putting the
> definition of `deserialize-info:adder-v0` in a different module, so that
> its version of `adder` has a contract, but then the binding isn't seen by
> `make-serialize-info`.

In case you still want to pursue that direction, you can use the pair
form of the second argument to `make-serialize-info`, which pairs a
symbol with a reference to an exporting module. See the example below.

(I think there's probably a library that's better to use than a raw
`variable-reference->module-path-index` plus `module-path-index-join`, 
but I forget.)

I don't see a way to blame the module that calls `deserialize`.



#lang racket

(module server racket
  (require racket/serialize)
  (provide (contract-out
[adder (-> natural-number/c (-> natural-number/c
natural-number/c))]))
  (struct adder (base)
#:property prop:procedure
(λ (this x)
  (+ (adder-base this) x))
#:property prop:serializable
(make-serialize-info (λ (this) (vector (adder-base this)))
 (cons 'deserialize-info:adder-v0
   (module-path-index-join
'(submod "." deserialize-info)
(variable-reference->module-path-index
 (#%variable-reference
 #f
 (or (current-load-relative-directory)
 (current-directory
  (define/contract make-adder
(-> natural-number/c (-> natural-number/c
 natural-number/c))
adder)
  
  (module* deserialize-info racket/base
(require (submod ".."))
(require racket/serialize)
(provide deserialize-info:adder-v0)
(define deserialize-info:adder-v0
  (make-deserialize-info adder
 (λ () (error 'adder
  "can't have cycles"))


(require 'server racket/serialize)

((deserialize (serialize (adder 5))) 'not-a-number)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-24 Thread Matthias Felleisen 

Ouch, my fault. I deleted the wrong bindings. 


> On Jul 24, 2017, at 1:58 PM, Philip McGrath  wrote:
> 
> Sorry for the crossed emails. If I understand what's happening correctly, the 
> code you sent only blames the "deserializing" module because it shaddows 
> `serialize` and `deserialize` to mean `values`, so the instance is never 
> actually deserialized or serialized and `deserialize-info:adder-v0` is never 
> consulted. If I remove the `local` block, the error is displayed in terms of 
> `+`.
> 
> #lang racket
> 
> (module server racket
>   (require racket/serialize)
>   
>   (provide (contract-out
> [adder (-> natural-number/c (-> natural-number/c 
> natural-number/c))]))
>   
>   (struct adder (base)
> #:property prop:procedure
> (λ (this x) (+ (adder-base this) x))
> #:property prop:serializable
> (make-serialize-info (λ (this) (vector (adder-base this)))
>  #'deserialize-info:adder-v0
>  #f
>  (or (current-load-relative-directory)
>  (current-directory
>   
>   (define deserialize-info:adder-v0
> (make-deserialize-info adder (λ () (error 'adder "can't have cycles"
>   
>   (module+ deserialize-info
> (provide deserialize-info:adder-v0)))
>   
> (require (submod "." server) racket/serialize)
> 
> (define x (serialize (adder 5)))
> (displayln x)
> (define f (deserialize x))
> (f 'not-a-number) 
> 
> -Philip
> 
> On Mon, Jul 24, 2017 at 12:50 PM, Philip McGrath  
> wrote:
> It occurs to me that one approach is to use the low-level `contract` form 
> directly. It gives better blame than `define/contract`, at least. The program:
> 
> #lang racket
> 
> (module server racket
>   (require racket/serialize)
>   
>   (provide (contract-out
> [adder (-> natural-number/c (-> natural-number/c 
> natural-number/c))]))
>   
>   (struct adder (base)
> #:property prop:procedure
> (λ (this x) (+ (adder-base this) x))
> #:property prop:serializable
> (make-serialize-info (λ (this) (vector (adder-base this)))
>  #'deserialize-info:adder-v0
>  #f
>  (or (current-load-relative-directory)
>  (current-directory
>   
>   (define deserialize-info:adder-v0
> (make-deserialize-info
>  (λ (base)
>(define inst (adder base))
>(contract (-> natural-number/c natural-number/c)
>  inst
>  '(definition adder)
>  `(deserialization ,inst)
>  (object-name adder)
>  #f))
>  (λ () (error 'adder "can't have cycles"
>   
>   (module+ deserialize-info
> (provide deserialize-info:adder-v0)))
>   
> (require (submod "." server) racket/serialize)
> 
> ((deserialize (serialize (adder 5))) 'not-a-number)
> 
> reports the error:
> 
> adder: contract violation
>   expected: natural-number/c
>   given: 'not-a-number
>   in: the 1st argument of
>   (-> natural-number/c natural-number/c)
>   contract from: (definition adder)
>   blaming: (deserialization #)
>(assuming the contract is correct)
> 
> 
> -Philip
> 
> On Mon, Jul 24, 2017 at 12:35 PM, Philip McGrath  
> wrote:
> That is precisely the contract violation I'd like to see reported, but, 
> without the shadowing of serialize and deserialize, the error is reported in 
> terms of `+`. (And, if it wasn't clear, I do intend to actually read and 
> write the serialized instance.)
> 
> I (think) I understand why deserialization strips the contract from the 
> instance: the contract is added at the module boundary using the 
> chaperone/impersonator infrastructure, and deserialization uses the 
> unprotected form of `adder` passed to `make-deserialize-info` within the 
> server module. 
> 
> What I don't understand is how to give `make-deserialize-info` a function 
> that (1) has a contract where (2) fulfilling the range part of the contract 
> becomes the deserializing module's obligation — if such a thing is possible. 
> Aside from attempts with `define/contract` (which as I now understand 
> achieved point 1 but not point 2), I've also tried putting the definition of 
> `deserialize-info:adder-v0` in a different module, so that its version of 
> `adder` has a contract, but then the binding isn't seen by 
> `make-serialize-info`.
> 
> -Philip
> 
> On Mon, Jul 24, 2017 at 7:30 AM, Matthias Felleisen  
> wrote:
> 
>> On Jul 23, 2017, at 10:50 PM, Philip McGrath  
>> wrote:
>> 
>> If I'm following correctly, I think that's what I was trying to do, but I'm 
>> unclear how to give `make-deserialize-info` a variant of `make-adder` that 
>> has a contract. The initial example with `define/contract` was the closest 
>> I've come: it at least reported violations in terms of `make-adder`

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-24 Thread Philip McGrath 
That is precisely the contract violation I'd like to see reported, but,
without the shadowing of serialize and deserialize, the error is reported
in terms of `+`. (And, if it wasn't clear, I do intend to actually read and
write the serialized instance.)

I (think) I understand why deserialization strips the contract from the
instance: the contract is added at the module boundary using the
chaperone/impersonator infrastructure, and deserialization uses the
unprotected form of `adder` passed to `make-deserialize-info` within the
server module.

What I don't understand is how to give `make-deserialize-info` a function
that (1) has a contract where (2) fulfilling the range part of the contract
becomes the deserializing module's obligation — if such a thing is
possible. Aside from attempts with `define/contract` (which as I now
understand achieved point 1 but not point 2), I've also tried putting the
definition of `deserialize-info:adder-v0` in a different module, so that
its version of `adder` has a contract, but then the binding isn't seen by
`make-serialize-info`.

-Philip

On Mon, Jul 24, 2017 at 7:30 AM, Matthias Felleisen 
wrote:

>
> On Jul 23, 2017, at 10:50 PM, Philip McGrath 
> wrote:
>
> If I'm following correctly, I think that's what I was trying to do, but
> I'm unclear how to give `make-deserialize-info` a variant of `make-adder`
> that has a contract. The initial example with `define/contract` was the
> closest I've come: it at least reported violations in terms of `make-adder`
> rather than `+`, but (as I now understand) it blamed the `server` module
> for all violations.
>
> -Philip
>
> On Sun, Jul 23, 2017 at 9:27 PM, Matthew Flatt  wrote:
>
>> The original example had an explicit deserializer:
>>
>> At Sun, 23 Jul 2017 19:54:43 -0500, Philip McGrath wrote:
>> >   (define deserialize-info:adder-v0
>> > (make-deserialize-info make-adder
>> >(λ () (error 'adder
>> > "can't have cycles"
>>
>> You're constructing the deserializer with `make-adder` --- the variant
>> from inside the `server` module, so it doesn't have a contract.
>>
>> I think this is where you want to draw a new boundary by giving
>> `make-deserialize-info` a variant of `make-adder` that has a contract.
>
>
>
>
> Don’t you just want this:
>
> #lang racket
>
> (module server racket
>   (require racket/serialize)
>
>   (provide (contract-out
> [adder (-> natural-number/c (-> natural-number/c
> natural-number/c))]))
>
>   (struct adder (base)
> #:property prop:procedure
> (λ (this x) (+ (adder-base this) x))
> #:property prop:serializable
> (make-serialize-info (λ (this) (vector (adder-base this)))
>  #'deserialize-info:adder-v0
>  #f
>  (or (current-load-relative-directory)
>  (current-directory
>
>   (define deserialize-info:adder-v0
> (make-deserialize-info adder (λ () (error 'adder "can't have
> cycles"
>
>   (module+ deserialize-info
> (provide deserialize-info:adder-v0)))
>
> (require (submod "." server) racket/serialize)
>
> (local ((define serialize values)
> (define deserialize values))
>   (define x (serialize (adder 5)))
>   (define f (deserialize x))
>   (f 'not-a-number))
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-24 Thread Matthias Felleisen 

> On Jul 23, 2017, at 10:50 PM, Philip McGrath  wrote:
> 
> If I'm following correctly, I think that's what I was trying to do, but I'm 
> unclear how to give `make-deserialize-info` a variant of `make-adder` that 
> has a contract. The initial example with `define/contract` was the closest 
> I've come: it at least reported violations in terms of `make-adder` rather 
> than `+`, but (as I now understand) it blamed the `server` module for all 
> violations.
> 
> -Philip
> 
> On Sun, Jul 23, 2017 at 9:27 PM, Matthew Flatt  > wrote:
> The original example had an explicit deserializer:
> 
> At Sun, 23 Jul 2017 19:54:43 -0500, Philip McGrath wrote:
> >   (define deserialize-info:adder-v0
> > (make-deserialize-info make-adder
> >(λ () (error 'adder
> > "can't have cycles"
> 
> You're constructing the deserializer with `make-adder` --- the variant
> from inside the `server` module, so it doesn't have a contract.
> 
> I think this is where you want to draw a new boundary by giving
> `make-deserialize-info` a variant of `make-adder` that has a contract.



Don’t you just want this: 

#lang racket

(module server racket
  (require racket/serialize)
  
  (provide (contract-out
[adder (-> natural-number/c (-> natural-number/c 
natural-number/c))]))
  
  (struct adder (base)
#:property prop:procedure
(λ (this x) (+ (adder-base this) x))
#:property prop:serializable
(make-serialize-info (λ (this) (vector (adder-base this)))
 #'deserialize-info:adder-v0
 #f
 (or (current-load-relative-directory)
 (current-directory
  
  (define deserialize-info:adder-v0
(make-deserialize-info adder (λ () (error 'adder "can't have cycles"
  
  (module+ deserialize-info
(provide deserialize-info:adder-v0)))
  
(require (submod "." server) racket/serialize)

(local ((define serialize values)
(define deserialize values))
  (define x (serialize (adder 5)))
  (define f (deserialize x))
  (f 'not-a-number))


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-23 Thread Philip McGrath 
If I'm following correctly, I think that's what I was trying to do, but I'm
unclear how to give `make-deserialize-info` a variant of `make-adder` that
has a contract. The initial example with `define/contract` was the closest
I've come: it at least reported violations in terms of `make-adder` rather
than `+`, but (as I now understand) it blamed the `server` module for all
violations.

-Philip

On Sun, Jul 23, 2017 at 9:27 PM, Matthew Flatt  wrote:

> The original example had an explicit deserializer:
>
> At Sun, 23 Jul 2017 19:54:43 -0500, Philip McGrath wrote:
> >   (define deserialize-info:adder-v0
> > (make-deserialize-info make-adder
> >(λ () (error 'adder
> > "can't have cycles"
>
> You're constructing the deserializer with `make-adder` --- the variant
> from inside the `server` module, so it doesn't have a contract.
>
> I think this is where you want to draw a new boundary by giving
> `make-deserialize-info` a variant of `make-adder` that has a contract.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-23 Thread Matthew Flatt 
The original example had an explicit deserializer:

At Sun, 23 Jul 2017 19:54:43 -0500, Philip McGrath wrote:
>   (define deserialize-info:adder-v0
> (make-deserialize-info make-adder
>(λ () (error 'adder
> "can't have cycles"

You're constructing the deserializer with `make-adder` --- the variant
from inside the `server` module, so it doesn't have a contract.

I think this is where you want to draw a new boundary by giving
`make-deserialize-info` a variant of `make-adder` that has a contract.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-23 Thread Matthias Felleisen 

I see. Not surprisingly serialization strips the contract of (structural) 
functions as you can see with this slightly different example: 


#lang racket

(module server racket
  (require racket/serialize)
  (provide (contract-out
[adder (-> natural-number/c (-> natural-number/c 
natural-number/c))]))
  
  (serializable-struct adder (base)
#:property prop:procedure
(λ (this x)
  (+ (adder-base this) x

(require 'server racket/serialize)

;; would report a contract violation in terms of adder
;; and blame this module
;((adder 5) 'not-a-number)

;; reports a contract violation in terms of +

(define f (adder 5))
(with-handlers ((exn? (λ (xn) (displayln xn
  (f 'not-a-number))
   
((deserialize (serialize f)) 'not-a-number)



> On Jul 23, 2017, at 10:06 PM, Philip McGrath  wrote:
> 
> Here is the problem with serialization, without my attempts to mitigate it:
> 
> #lang racket
> 
> (module server racket
>   (require racket/serialize)
>   (provide (contract-out
> [adder (-> natural-number/c (-> natural-number/c
> natural-number/c))]))
>   (serializable-struct adder (base)
> #:property prop:procedure
> (λ (this x)
>   (+ (adder-base this) x
> (require 'server racket/serialize)
> 
> ;; would report a contract violation in terms of adder
> ;; and blame this module
> ;((adder 5) 'not-a-number)
> 
> ;; reports a contract violation in terms of +
> ((deserialize (serialize (adder 5))) 'not-a-number)
> 
> -Philip
> 
> On Sun, Jul 23, 2017 at 9:02 PM, Matthias Felleisen  > wrote:
> [replying to myself]
> 
> 
> > On Jul 23, 2017, at 9:58 PM, Matthias Felleisen  > > wrote:
> >
> >
> > At some point I wrote all this up for the contract doc (as the opening 
> > paragraphs). I can’t see it right now.
> 
> 
> Still there:
> 
>http://docs.racket-lang.org/guide/contract-boundaries.html 
> 
> 
> 
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-23 Thread Philip McGrath 
Here is the problem with serialization, without my attempts to mitigate it:

#lang racket

(module server racket
  (require racket/serialize)
  (provide (contract-out
[adder (-> natural-number/c (-> natural-number/c
natural-number/c))]))
  (serializable-struct adder (base)
#:property prop:procedure
(λ (this x)
  (+ (adder-base this) x
(require 'server racket/serialize)

;; would report a contract violation in terms of adder
;; and blame this module
;((adder 5) 'not-a-number)

;; reports a contract violation in terms of +
((deserialize (serialize (adder 5))) 'not-a-number)

-Philip

On Sun, Jul 23, 2017 at 9:02 PM, Matthias Felleisen 
wrote:

> [replying to myself]
>
>
> > On Jul 23, 2017, at 9:58 PM, Matthias Felleisen 
> wrote:
> >
> >
> > At some point I wrote all this up for the contract doc (as the opening
> paragraphs). I can’t see it right now.
>
>
> Still there:
>
>http://docs.racket-lang.org/guide/contract-boundaries.html
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-23 Thread Matthias Felleisen 
[replying to myself]


> On Jul 23, 2017, at 9:58 PM, Matthias Felleisen  wrote:
> 
> 
> At some point I wrote all this up for the contract doc (as the opening 
> paragraphs). I can’t see it right now. 


Still there: 

   http://docs.racket-lang.org/guide/contract-boundaries.html



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-23 Thread Matthias Felleisen 

> On Jul 23, 2017, at 9:43 PM, Philip McGrath  wrote:
> 
> Aha — so it isn't really an issue with serialization at all. If I (now) 
> understand this correctly, when a function produces a contracted higher-order 
> result, it is the responsibility of the caller of the original function to 
> ensure that the result function is always applied to appropriate arguments. 
> That would explain why this version blames intermediary:
> 
> #lang racket
> 
> (module server racket
>   (provide (contract-out
> [adder (-> natural-number/c (-> natural-number/c
> natural-number/c))]))
>   (struct adder (base)
> #:property prop:procedure
> (λ (this x)
>   (+ (adder-base this) x
> (module intermediary racket
>   (require (submod ".." server))
>   (provide add5)
>   (define add5
> (adder 5)))
> (require 'intermediary)
> (add5 'not-a-number)
> 
> I had previously intuited that the obligation would be on the caller of the 
> result function, whoever that might be.


A contract is always between two parties.  For define/contract, it’s the 
definition and the surrounding module (which is btw a nested contract party). 
If a party promises to always apply some function to an odd number (say) but 
then hands out the function to other parties — without protection — it is its 
fault if the function is misused (abused). 

For module exports, it’s obviously the module and its client(s). Here server 
and intermediary enter into a contract that obliges the latter to apply adder 
to a natural number and the function that it creates also to an N. The 
intermediary module uses add5 correctly but then hands out the result w/o 
protection. So when the client (main module) misuses add5, intermediary must be 
blamed. It promised to hand an N to the (curried) second argument of adder and 
didn’t. — The fix is to either not hand out add5 or to equip it with a contract 
so that the client (main) module is also obliged to call it with an N. 

At some point I wrote all this up for the contract doc (as the opening 
paragraphs). I can’t see it right now. 


> When serialization is in the mix, is there a correct way for server to 
> protect itself from instances of adder being abused after they are 
> deserialized? 


Serialization is semantically the identify function. I can’t see how it plays a 
role. 


> 
> 
> -Philip
> 
> On Sun, Jul 23, 2017 at 8:16 PM, Matthias Felleisen  > wrote:
> 
>> On Jul 23, 2017, at 8:54 PM, Philip McGrath > > wrote:
>> 
>> I'm confused about why the following program is blaming the server for the 
>> client's misuse of an applicable struct instance. More generally, I've tried 
>> doing this in several different ways, and I can't figure out how to make 
>> applicable structs that are still protected by contracts after 
>> deserialization and blame the client module for misusing them.
>> 
>> Thanks,
>> Philip
>> 
>> #lang racket
>> 
>> (module server racket
>>   (require racket/serialize)
>>   (provide (contract-out
>> [adder (-> natural-number/c (-> natural-number/c
>> natural-number/c))]))
>>   (struct adder (base)
>> #:property prop:procedure
>> (λ (this x)
>>   (+ (adder-base this) x))
>> #:property prop:serializable
>> (make-serialize-info (λ (this) (vector (adder-base this)))
>>  #'deserialize-info:adder-v0
>>  #f
>>  (or (current-load-relative-directory)
>>  (current-directory
>>   (define/contract make-adder
>> (-> natural-number/c (-> natural-number/c
>>  natural-number/c))
>> adder)
> 
> 
> 
> You defined make-adder with a contract. As far as it is concerned, its 
> contract is with the surrounding module, which is server. Hence if it is 
> misapplied, the server broke the contract of always protecting its entry 
> channels (with a natural-number/c test). 
> 
> 
> 
> 
> 
>>   (define deserialize-info:adder-v0
>> (make-deserialize-info make-adder
>>(λ () (error 'adder
>> "can't have cycles"
>>   (module+ deserialize-info
>> (provide deserialize-info:adder-v0)))
>>   
>> 
>> (require 'server racket/serialize)
>> 
>> ((deserialize (serialize (adder 5))) 'not-a-number)
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 

-- 
You received this message because

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-23 Thread Philip McGrath 
Aha — so it isn't really an issue with serialization at all. If I (now)
understand this correctly, when a function produces a contracted
higher-order result, it is the responsibility of the caller of the original
function to ensure that the result function is always applied to
appropriate arguments. That would explain why this version
blames intermediary:

#lang racket

(module server racket
  (provide (contract-out
[adder (-> natural-number/c (-> natural-number/c
natural-number/c))]))
  (struct adder (base)
#:property prop:procedure
(λ (this x)
  (+ (adder-base this) x
(module intermediary racket
  (require (submod ".." server))
  (provide add5)
  (define add5
(adder 5)))
(require 'intermediary)
(add5 'not-a-number)


I had previously intuited that the obligation would be on the caller of the
result function, whoever that might be.

When serialization is in the mix, is there a correct way for server to
protect itself from instances of adder being abused after they are
deserialized?


-Philip

On Sun, Jul 23, 2017 at 8:16 PM, Matthias Felleisen 
wrote:

>
> On Jul 23, 2017, at 8:54 PM, Philip McGrath 
> wrote:
>
> I'm confused about why the following program is blaming the server for the
> client's misuse of an applicable struct instance. More generally, I've
> tried doing this in several different ways, and I can't figure out how to
> make applicable structs that are still protected by contracts after
> deserialization and blame the client module for misusing them.
>
> Thanks,
> Philip
>
> #lang racket
>
> (module server racket
>   (require racket/serialize)
>   (provide (contract-out
> [adder (-> natural-number/c (-> natural-number/c
> natural-number/c))]))
>   (struct adder (base)
> #:property prop:procedure
> (λ (this x)
>   (+ (adder-base this) x))
> #:property prop:serializable
> (make-serialize-info (λ (this) (vector (adder-base this)))
>  #'deserialize-info:adder-v0
>  #f
>  (or (current-load-relative-directory)
>  (current-directory
>   (define/contract make-adder
> (-> natural-number/c (-> natural-number/c
>  natural-number/c))
> adder)
>
>
>
>
> You defined make-adder with a contract. As far as it is concerned, its
> contract is with the surrounding module, which is server. Hence if it is
> misapplied, the server broke the contract of always protecting its entry
> channels (with a natural-number/c test).
>
>
>
>
>
>   (define deserialize-info:adder-v0
> (make-deserialize-info make-adder
>(λ () (error 'adder
> "can't have cycles"
>   (module+ deserialize-info
> (provide deserialize-info:adder-v0)))
>
>
> (require 'server racket/serialize)
>
> ((deserialize (serialize (adder 5))) 'not-a-number)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Blame for contracts on applicable serializable structs

2017-07-23 Thread Matthias Felleisen 

> On Jul 23, 2017, at 8:54 PM, Philip McGrath  wrote:
> 
> I'm confused about why the following program is blaming the server for the 
> client's misuse of an applicable struct instance. More generally, I've tried 
> doing this in several different ways, and I can't figure out how to make 
> applicable structs that are still protected by contracts after 
> deserialization and blame the client module for misusing them.
> 
> Thanks,
> Philip
> 
> #lang racket
> 
> (module server racket
>   (require racket/serialize)
>   (provide (contract-out
> [adder (-> natural-number/c (-> natural-number/c
> natural-number/c))]))
>   (struct adder (base)
> #:property prop:procedure
> (λ (this x)
>   (+ (adder-base this) x))
> #:property prop:serializable
> (make-serialize-info (λ (this) (vector (adder-base this)))
>  #'deserialize-info:adder-v0
>  #f
>  (or (current-load-relative-directory)
>  (current-directory
>   (define/contract make-adder
> (-> natural-number/c (-> natural-number/c
>  natural-number/c))
> adder)



You defined make-adder with a contract. As far as it is concerned, its contract 
is with the surrounding module, which is server. Hence if it is misapplied, the 
server broke the contract of always protecting its entry channels (with a 
natural-number/c test). 





>   (define deserialize-info:adder-v0
> (make-deserialize-info make-adder
>(λ () (error 'adder
> "can't have cycles"
>   (module+ deserialize-info
> (provide deserialize-info:adder-v0)))
>   
> 
> (require 'server racket/serialize)
> 
> ((deserialize (serialize (adder 5))) 'not-a-number)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.