[racket] sharing an expensive computation required in procedure and its contract?

From: Alexander D. Knauth (alexander at knauth.org)
Date: Sun Jul 20 14:47:48 EDT 2014

On Jul 20, 2014, at 1:56 PM, Jon Zeppieri <zeppieri at gmail.com> wrote:

> I feel like this has come up before, but I can't seem to find the
> discussion in the archive.

Was this what you were thinking of?
http://lists.racket-lang.org/users/archive/2013-November/060427.html
http://lists.racket-lang.org/users/archive/2013-November/060429.html
http://lists.racket-lang.org/users/archive/2013-November/060430.html
http://lists.racket-lang.org/users/archive/2013-November/060433.html
http://lists.racket-lang.org/users/archive/2013-November/060437.html

Although this won’t really help you much.  It ended up with "abusing the contract system” by making a contract that transformed the arguments before passing them to the function, and not for producing a different value that would be used by both.  And it’s not a good idea anyway.  

> I have a procedure that needs to perform a
> fairly expensive computation which is needed both for checking the
> inputs and for producing output. I'd like to avoid computing it twice,
> and I'd also like to use contracts to check the inputs. Is there any
> reasonable way to do this?
> 
> The code is like this:
> 
> (define (do-stuff x y z)
>  (define important-value (expensive x y z))
>  ... do stuff with important-value ...)
> 
> (provide/contract
>  [do-stuff (->i [x ...] [y ...] [z (x y)
> contract-that-depends-on-important-value]) [result ...])])
> 
> 
> I could memoize the expensive computation, but that would require
> something like an LRU cache to avoid memory problems, and I'd rather
> not have to worry about that.
> 
> Alternatively, I could shift things around so that the contract is on
> the procedure that generates important-value, but then blame reporting
> would be incorrect.
> 
> Any ideas?
> 
> -Jon
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users



Posted on the users mailing list.