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

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.

-- Matthias