If you have the standard, garden-variety collection of FPers, you will get huge-pushback because your contracts look like (and can be expressed as) types. Some smart-a..k will say "but I can do this in Haskell" and the rest of the room will nod their wise heads.
1. Always use contracts that cannot be expressed as types in an obvious type system. 2. Show a higher-order contract and flavors that push this idea hard. Consider using d/dx or indefinite adaptive integral as functions on (real? -> real?) -> (real?^n -> real?) AND THEN say that the d/dx function approximates the slope up to epsilon or that the adaptive integrator approximates the area up to some blah. 3. For the smack-down, contracts tend to reveal some things that are "intensional" (part of the implementation). Also, contracts can easily shift the algorithmic complexity if you're careless. See binary-search but impose sorted? as a predicate on the vector that flows into the function. Good luck -- Matthias On Sep 3, 2013, at 2:37 AM, Daniel Prager <[email protected]> wrote: > I'm giving this talk > > > http://www.slideshare.net/DanielPrager/introduction-to-contracts-and-functional-contracts > > to the local functional programming user group in a few days. > > Any feedback or corrections appreciated. > > > Many thanks > > Dan > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
