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. [Of course, the user can call an unchecked version of that function and has explicitly accepted the responsibility of ensuring that contract is fulfilled].<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 <<a href="mailto:grettke@acm.org">grettke@acm.org</a>> 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 <<a href="mailto:robby@cs.uchicago.edu">robby@cs.uchicago.edu</a>> wrote:<br>
> I guess you're getting at something deeper here, but their role is to<br>
> add additional, checked specifications to the program (with proper<br>
> blame assignment, natch) so we know when something has gone wrong<br>
> 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>
> Maybe you want to read this:<br>
> <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>