> To ensure that an input string represents a valid address, the contract > needs to parse the string. The constructor for the address structure > also needs to parse the string to get the data, so it's redundant. > > (I didn't come up with a nice solution though)
BTW it's not that I want to abuse contracts — on the contrary, contracts are such a handy & distinctive idiom that I keep wanting to fold more of my input & output processing into them. For instance, I've thought about creating a pattern like this: (define/lambda-contract (f x) (in/lc . -> . out/lc) (do-stuff-to x)) That expands into something like this: (out/lc (do-stuff-to (in/lc x)) Where each "lambda contract" embodies both a data-conversion step and traditional contract-checking step: (define in/lc (lambda (x) (in-processing (in/c x)))) (define out/lc (lambda (x) (out/c (out-processing x)))) So (f x) ultimately evaluates to this: (out/c (out-processing (do-stuff-to (in-processing (in/c x))))) The contracts are still at the function boundaries, where they need to be. But there's an obvious problem on the input side, because in-processing wants x, not the result of (in/c x). (And probably other obvious problems I'm not considering, because I haven't figured out how to cure that one.) ____________________ Racket Users list: http://lists.racket-lang.org/users
