> On Jul 23, 2017, at 9:43 PM, Philip McGrath <phi...@philipmcgrath.com> 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 <matth...@ccs.neu.edu > <mailto:matth...@ccs.neu.edu>> wrote: > >> On Jul 23, 2017, at 8:54 PM, Philip McGrath <philip.mcgr...@gmail.com >> <mailto:philip.mcgr...@gmail.com>> 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 >> <mailto:racket-users+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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.
