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

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

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

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

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

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 >

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

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

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

> 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

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

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

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

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

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

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

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))]))

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

[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:

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

> 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

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

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

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

> 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

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

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