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 -050
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 t
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
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 neve
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-nu
> On Jul 24, 2017, at 1: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 t
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 s
> 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'v
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` rathe
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")
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
natur
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))]))
(se
[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 receiv
> 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
> ensur
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
> 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
> appli
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
deserializa
17 matches
Mail list logo
