On Fri, Dec 1, 2017 at 10:08 PM, Ben Greenman <benjaminlgreen...@gmail.com>
wrote:

> Let me make sure I understand:
>
> 1. A converter is like a two-way function, lets say (A . <-> . B)
> 2. If someone composes two incompatible converters, like (integer? .
> <-> . symbol?) and (string? . <-> . boolean?) then they should get an
> error that points to the place where they tried to do the composing.
>
> It looks like the code above is using the contract on
> `compose-converters` to meet goal #2.
> Is that all right?
>

Yes, all of this is correct.

I will have to think about/play with your suggestion some more because I
haven't used parametric->/c before (beyond playing with it when I've
thought it might be what I was looking for and decided it wasn't).

However, I do know that at least one of the "too many things at once" that
the contract on compose-converters is doing is because of a simplification
I made for this example. In the actual code where I encountered this, I
provide only a protected interface for constructing values, so the
equivalent of:

(define/contract make-converter
  (->i ([encoded/c contract?]
        [encoded->native
         (encoded/c native/c)
         (-> encoded/c native/c)]
        [native/c contract?]
        [native->encoded
         (encoded/c native/c)
         (-> native/c encoded/c)])
       [_ converter?])
  converter)


So I definitely agree that it shouldn't be up to the contract on
compose-converters to ensure that its arguments are valid converters; its
job should just be to ensure that they are compatible.

-Philip

-- 
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.

Reply via email to