I use the unchecked versions of the functions for calls between modules, which occurs fairly often in the science collection. For example, the cdf for the Gaussian random distribution (in the gaussian.ss module) calls the error function (in the special-functions.ss module). As far as I know there is nothing similar to the concept of a "friend" module. [Nor am I requesting one.]<br>
<br>I also don't recommend calling the unchecked version of the code unless you are TOTALLY willing to accept the consequences. In my large analysis code I am often willing to do that after they are debugged and I'm just push lots of data through it.<br>
<br><div class="gmail_quote">On Fri, Jan 25, 2008 at 10:29 AM, Matthias Felleisen <<a href="mailto:matthias@ccs.neu.edu">matthias@ccs.neu.edu</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 style="">
<br><div><div class="Ih2E3d"><div>On Jan 25, 2008, at 11:54 AM, Doug Williams wrote:</div><br><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></div></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 class="Ih2E3d"><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></div></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></div><div>;; --- </div><div><br></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>
</div><font color="#888888"><div>-- Matthias</div></font><div><div></div><div class="Wj3C7c"><div><br></div><div><br></div><div><br></div><div><br></div><div><br></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 <<a href="mailto:grettke@acm.org" target="_blank">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>On Jan 25, 2008 7:23 AM, Robby Findler <<a href="mailto:robby@cs.uchicago.edu" target="_blank">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><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>_________________________________________________<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: 0px;">_________________________________________________</div><div style="margin: 0px;"><span> </span>For list-related administrative tasks:</div><div style="margin: 0px;">
<span> </span><a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a></div> </blockquote></div></div></div><br></div></blockquote></div><br>