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
16 matches
Mail list logo
