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

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20080125/5a6bed5e/attachment.html>