[racket] contracts on liberal function inputs: avoiding duplicate effort

On 11/18/2013 12:03 PM, Matthew Butterick wrote:
> In a function that permits liberal inputs, I often find that the input processing I do in a contract is duplicated at the beginning of the body of the function. Is this avoidable?
>
> Certain functions want to be liberal with input because there are multiple common ways to represent the data. For instance, I have a function that operates on CSS RGB colors. This function should be prepared to accept these forms of input & understand that they're all the same:
>
> "#c00"
> "#cc0000"
> '("204" "0" "0")
> #xcc0000
> '(0.8 0 0)
>
> Let's say that my internal representation of an RGB color is described by the contract rgb-color/c:
>
> (define rgb-color/c (list/c (real-in 0 1) (real-in 0 1) (real-in 0 1)))
>
> But I can't use rgb-color/c as the input contract for the function because it's too narrow. So I make a second contract that tests for things that can be converted to an rgb-color:
>
> (define (rgb-colorish? x) (or/c rgb-color/c [tests for the other input formats ...] )
>
> To determine if the input is rgb-colorish?, this contract usually just ends up trying to convert the input to rgb-color. If it works, then the contract returns true.
>
> But after the contract returns, I have to convert the input to an rgb-color anyhow. So I'm doing exactly the same work that the contract just finished. If the conversion is expensive, I'm doing it twice.

We usually just don't worry about the conversion happening twice. Or we 
do what Matthias said. Or we apply a fast approximate contract (or none 
at all) and then do the conversion and error checking together inside 
the function.

But... by abusing the contract system a little bit, though, we can get 
it to do the conversion for you.

Here's a "contract" combinator that takes a conversion function that 
returns #f to indicate failure/rejection and any other value to 
represent the converted result.

 > (define (make-named-conversion-contract name convert)
     (define ((proj blame) v)
       (cond [(convert v )
              => values]
             [else
              (raise-blame-error blame v
                                 '(expected: "~a" given: "~e")
                                 name v)]))
     (make-contract #:name name #:projection proj))

Here's a "contract" that checks that a value is real, and if so produces 
its absolute value.

 > (define abs/c
     (make-named-conversion-contract
      'abs/c
      (lambda (v) (and (real? v) (abs v)))))

And here's a function using the converting "contract":

 > (define/contract f (-> abs/c real?)
     (lambda (x) x))
 > (f 10)
10
 > (f -12)        ;; <-- !!!
12
 > (f 'hello)
f: contract violation
  expected: abs/c
  given: 'hello
  ....

Of course, these are not really contracts as we understand them. The 
docs for 'make-contract' say not to do this, if you read them carefully. 
So beware. I'm kind of curious what other people think of this 
application of the contract system, actually.

Ryan