Hi Matthias Thank-you for your sage advice:
On Tue, Sep 3, 2013 at 11:54 PM, Matthias Felleisen <[email protected]> wrote: 1. Always use contracts that cannot be expressed as types > in an obvious type system. I'll work on my examples. I may also throw in an example in typed racket to show the types and contracts working together. 2. Show a higher-order contract and flavors that push this > idea hard. Consider using d/dx or indefinite adaptive integral ... > I'm a little bit wary of showing (only) a calculus-flavoured example because I don't want to give the impression that the higher-order contracts are just for mathematical applications. I'll try to come up with / search for a more "down to earth" example, but if anyone has a practical, non-math, suggestion handy, please point me to it! I confess that as I have been learning about higher-order contracts I wondered whether (instead) types + flat-contracts would suffice in practice as a worse-is-better compromise. > 3. For the smack-down, contracts tend to reveal some things that > are "intensional" (part of the implementation). Sounds bad for information hiding. What's an example of this? > 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. Makes sense. I'll add it. Good luck -- Matthias Thanks! Dan
____________________ Racket Users list: http://lists.racket-lang.org/users
