[plt-scheme] contracts.ss: Can you disable them at runtime?

On 5/17/07, Matthias Felleisen <matthias at ccs.neu.edu> wrote:
>
> On May 17, 2007, at 10:16 AM, Richard Cobbe wrote:
>
> > On Thu, May 17, 2007 at 09:59:16AM -0400, Matthias Felleisen wrote:
> >>
> >>  On May 17, 2007, at 9:41 AM, Richard Cobbe wrote:
> >>
> >>> I've often wanted to disable them for certain modules even "during
> >>> practice."  When I'm running test cases and debugging, having to
> >>> repeatedly
> >>> recompile a module with complicated structure and contract
> >>> definitions is
> >>> slow enough to be very annoying and almost slow enough to be
> >>> impractical.
> >>
> >>  It sounds like you're using contracts as a substitute for types
> >
> > Yes, for two reasons:
> >
> >   1) The last time I looked into this (several months ago) Typed
> > Scheme
> >      wasn't yet ready to do the things I want from a type or contract
> >      system.  Perhaps it's time to revisit that decision.
> >
> >   2) I understand the pragmatics of using a type system.  Therefore, I
> >      understand the pragmatics of using a contract system as though
> > it were
> >      a type system.  I don't understand the pragmatics of using a
> > contract
> >      system in another way.
> >
> > Side issue: based on conversations with other people in the lab, I
> > know
> > that I'm not the only one who doesn't really understand the
> > pragmatics of
> > using contracts.  Addressing this shortcoming would help
> > significantly in
> > the adoption of contracts, I believe.
>
> Contracts should be seen as a tool that is used relative to the power of
> the built-in type system.
>
> If you program in static type (ST) system, such as Typed Scheme,
> your types usually can't express invariants such as prime -> prime.
> You use contracts for that to narrow down the type int -> int.
>
> If you program in a dynamically typed language, you should rely on the
> dynamic checks that are built it. That's why you chose DL over SL. So
> you do the usual thing: you imagine a type system that helps you reason.
>
> For invariants that are complex and inexpensive to check, such as
> prime? -> prime?, use them. For expensive to check, think thrice.
> For simplistic things, such as number? -> number? consider whether
> they are really useful.
>
> This is a grey scale but I tend to see an error on the cautious side
> way too often.

This topic is worth further exploration and documentation along with
the contract manual (because I know you guys aren't busy enough
already of course ;) )

Perhaps it is obvious when you think about it, but the first thing
that occurred to me was to use contracts as a type system. That is not
really the spirit of them, in a dynamic OR in a statically typed
language. The type system catches type errors of course, but what are
the other characteristics...

That said, the notion of thinking about those properties (rather than
the types) is implicitly explored in the section on Mitchell and
McKim's book in 'A Guide to PLT Scheme Contracts'.

Still, this notion is worth mentioning early on,.