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?


Anyway, I think the contract for `compose-converters` should ONLY try
to make sure `compose-converters` is doing the right thing. Something
like:

```
(define/contract (compose-converters g f)
  (parametric->/c [A B C]
    (-> (B . <-> . C)
        (A . <-> . B)
        (A . <-> . C)))
  ....)
```

Then the `...` should try to meet goal #2 by putting a stronger
contract on one of the converters (using something like
`define/contract`).


I don't think ->d is a good answer because I don't think a dependent
contract on "compose" is a good answer -- it's doing too many things
at once.

[[ Now I'm thinking the docs should make ->d even harder to find ...
every time I ever thought that I wanted ->d, I was better off making a
new contract combinator and using it with -> or something. ]]

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