<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On Jan 25, 2008, at 11:54 AM, Doug Williams wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I use contracts extensively in the science collection (which I would call a real project - several dozen modules (many thousands of lines of code) distributed as a single PLaneT collection).  Some contracts are 'expensive' (in terms of computation time), but I still include them.  For example, the median function requires a sorted vector of real numbers as input and the contract enforces that.  I also provide unchecked versions of all of the functions (e.g. unchecked-median) that can be called if a user explicitly wants to avoid the contract check (and accepts the consequences).  For example, I call the unchecked versions internally when I know the contract will not be violated - typically, because they are called from within another function whose contract has been checked.  </blockquote><div><br class="webkit-block-placeholder"></div><div>If the definitions of functions f and g reside in the same module, there is NO need to call an unchecked version of f from g (or vice versa). The contract system already does this for you. It trust all code that lives within the same boundary. </div><div><br></div><blockquote type="cite">[Of course, the user can call an unchecked version of that function and has explicitly accepted the responsibility of ensuring that contract is fulfilled].</blockquote><div><br class="webkit-block-placeholder"></div><div>This is backwards from how contracts and run-time checking works. Say a client C uses function f from your module M. If f fails, it is likely that the error message will blame M for the failure. (We are working on replacing 'likely' with 'true'.) At least at first glance the designer of C has no clue that it isn't M's failure. If, however, you export ONLY f with contracts, the error message is going to blame C and the designer of C has no choice but to accept the debugging obligation. </div><div><br class="webkit-block-placeholder"></div><div>;; --- </div><div><br class="webkit-block-placeholder"></div><div>We call this the "pressure of the market place" and have wanted to conduct an experiment along those lines. Alas, it has landed between cracks. </div><div><br class="webkit-block-placeholder"></div><div>-- Matthias</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><br><blockquote type="cite"><br> <br>One place I don't use contracts in the science collection is in the ordinary differential equation solver.  This has many functions that are computationally intensive and are typically used within very tight loops.  When I originally wrote (and distributed) the science collection, there was a big performance hit with the contracts on these function, so I removed them.  I think those performance hits have been largely eliminated and I plan on revisiting this is the next major version of the science collection (which I plan to release with PLT Scheme V4).  [And, of course there will still be unchecked versions of these that can be used when performance is critical.]<br> <br>These are just my thoughts and the way I approached it.  Your mileage may vary.<br><br>Doug<br><br><div class="gmail_quote">On Fri, Jan 25, 2008 at 8:51 AM, Grant Rettke &lt;<a href="mailto:grettke@acm.org">grettke@acm.org</a>&gt; wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Jan 25, 2008 7:23 AM, Robby Findler &lt;<a href="mailto:robby@cs.uchicago.edu">robby@cs.uchicago.edu</a>&gt; wrote:<br> &gt; I guess you're getting at something deeper here, but their role is to<br> &gt; add additional, checked specifications to the program (with proper<br> &gt; blame assignment, natch) so we know when something has gone wrong<br> &gt; sooner, rather than later. This makes it easier to fix, etc.<br> <br> </div>Well, yes. In a past post there was a long discussion about the role<br> of contracts and how they ought not replace a type system, among other<br> things, but the comments were more general in nature.<br> <br> Since you guys maintain a large Scheme codebase I figure that you have<br> applied contracts, and have a better sense of their "sweet spot" when<br> it comes to how they are used in "real projects". Perhaps even you<br> guys have internalized/standardized (spoken or unspoken) some<br> practices like "in such and such a situation, be sure to add contracts<br> because it helps somehow".<br> <div class="Ih2E3d"><br> &gt; Maybe you want to read this:<br> &gt;   <a href="http://pre.plt-scheme.org/docs/html/guide/contracts.html" target="_blank">http://pre.plt-scheme.org/docs/html/guide/contracts.html</a><br> <br> </div>I will check that out.<br> <div><div></div><div class="Wj3C7c">_________________________________________________<br>  For list-related administrative tasks:<br>  <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a><br> </div></div></blockquote></div><br><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_________________________________________________</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><span class="Apple-converted-space">  </span>For list-related administrative tasks:</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><span class="Apple-converted-space">  </span><a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a></div> </blockquote></div><br></body></html>