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

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

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.

On Fri, Jan 25, 2008 at 10:29 AM, Matthias Felleisen <matthias at ccs.neu.edu>
wrote:

>
> 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/e94193e1/attachment.html>