Typed Racket's implementation uses conditional contracts internally. There's a switch that determines, at syntax time, whether contracts are added or not. This can completely eliminate the run time overhead of contracts.
This cannot retroactively enable/disable contracts to compiled code; you need to edit the file to flip the switch and then recompile Typed Racket. The relevant code is in `collects/typed-racket/utils/utils'. Look for `enable-contracts?', `provide/cond-contract', `define/cond-contract', etc. We've thought about packaging it up as a separate library, but since the switch would have to belong to the library's client, we couldn't think of a clean interface. Vincent At Fri, 18 May 2012 18:24:51 -0400, Neil Van Dyke wrote: > > Any new thoughts on adding a feature for disabling contracts? > > In the past, I have been concerned about introducing contracts into > large performance-sensitive apps, since I didn't know the performance > impact. I couldn't measure the performance impact without a large > amount of work that might have to then be thrown away. The solution was > to simply not try using contracts. > > I am newly interested in disabling contracts because my new code > documentation tool encourages the use of contracts, as well as > developing your modules as PLaneT packages. However, as I am converting > all my PLaneT packages to use contracts, I fear this will make the > packages less useful to people who don't want the contract overhead. > > Or, if no one is persuaded that this might be a good thing, perhaps > there's a submodules angle that makes implementing disable-able > contracts interesting to someone? If so, it might also be relevant to > Typed Racket. > > Neil V. > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users