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.