[plt-scheme] The role of contracts in the maintenance and ongoing development of DrScheme

On Jan 25, 2008, at 11:54 AM, Doug Williams wrote:

> 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.

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.

> [Of course, the user can call an unchecked version of that function  
> and has explicitly accepted the responsibility of ensuring that  
> contract is fulfilled].

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.

;; ---

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.

-- Matthias






>
>
> 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.]
>
> These are just my thoughts and the way I approached it.  Your  
> mileage may vary.
>
> Doug
>
> On Fri, Jan 25, 2008 at 8:51 AM, Grant Rettke <grettke at acm.org> wrote:
> On Jan 25, 2008 7:23 AM, Robby Findler <robby at cs.uchicago.edu> wrote:
> > I guess you're getting at something deeper here, but their role  
> is to
> > add additional, checked specifications to the program (with proper
> > blame assignment, natch) so we know when something has gone wrong
> > sooner, rather than later. This makes it easier to fix, etc.
>
> Well, yes. In a past post there was a long discussion about the role
> of contracts and how they ought not replace a type system, among other
> things, but the comments were more general in nature.
>
> Since you guys maintain a large Scheme codebase I figure that you have
> applied contracts, and have a better sense of their "sweet spot" when
> it comes to how they are used in "real projects". Perhaps even you
> guys have internalized/standardized (spoken or unspoken) some
> practices like "in such and such a situation, be sure to add contracts
> because it helps somehow".
>
> > Maybe you want to read this:
> >   http://pre.plt-scheme.org/docs/html/guide/contracts.html
>
> I will check that out.
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20080125/147ebd2c/attachment.html>