[racket-dev] Feature request - contract form that splits provide/contract into two parts

An alternate flow which I think aligns slightly better with graduated code
validity vs cost (effort)?

0. Quick and dirty code spikes, snippets in R.
1. Write prototype code directly in TR.
  - Liberal addition via Step 0 efforts, pre and current with Step 1.
  - TR is very lightweight.
  - The single additional type line is negligible in effort and is the
singular most concise, effective expression of documentation that one can
put in their code.
  - The benefits of instant TR feedback in DR while coding, IMHO, far out
weight considerations of rapid prototyping without TR.
  - TR in effect is/should be eliding contracts where static type checking
can prove safe absence and implicitly inserting contracts contracts based
on safety settings.
2. If you like your prototype and you know it will be around awhile:
  - Selectively transform unchecked contracts into checked contracts
  - Add contracts which increase code robustness value with consideration
of performance overhead. *[1,2]

Essentially
Step 1: Write prototypes in statically typed code from the get go in TR.
Step 2: Turn prototypes into high quality code by adding runtime contracts.

[*1] Essentially considered effort by the programmer towards marked
enhancement of production/library code validity with all the
design-by-contract, pre/post assertions, IO boundary assertions, bounds
assertions, etc that a static type checker cannot handle.
[*2] The risk is that Step 2 is under appreciated and may not happen,
therefore an emphasis in starting in CR (Contract Racket) and then later
splitting contracts into orthogonal static (TR) and runtime (CR) proofing
of code validity, thus guaranteeing some effort in Step 2 happened at all.
 Step 1 in no way absolves the programmer of Step 2.



On Fri, Dec 28, 2012 at 9:42 AM, Matthias Felleisen <matthias at ccs.neu.edu>wrote:

>
> On Dec 27, 2012, at 8:58 PM, Harry Spier wrote:
>
> > On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen
> > <matthias at ccs.neu.edu> wrote:
> >>
> >> It is critical to inform clients of the services that a module
> >> provides. In the absence of types, contracts are the closest
> >> information we have.
> > AND
> > On Fri, Dec 14, 2012 at 11:43 AM, Ray Racine <ray.racine at gmail.com>
> wrote:
> >> For the TR folks you can have your cake and eat it with a cup of coffee
> with
> >> `provide'.  TR Rules
> >
> > Given the above, should you be using Typed Racket instead of contracts
> > whenever possible?  Are there cases where if you have the choice you
> > should prefer contracts instead of using Typed Racket
>
>
> No for several reasons:
>
> 1. Our contracts are actually more powerful than our types:
>
>  see
> http://www.ccs.neu.edu/home/matthias/Style/style/Units_of_Code.html#(part._.Contracts)
>
> especially contract for celsius->fahrenheit for an example.
> (In principle, our type system can express this idea.)
>
> 2. We see Racket as a continuum:
>  -- write a script, throw it away
>  -- or grow the script/create prototype with informal contracts and data
> descriptions
>  -- if you like your prototype and you know it'll be around for a while,
>         turn informal contracts into checked contracts
>         weighing performance impact against importance of checks.
>  -- if you ever maintain any of these modules, split contracts into types
> and residual contracts.
>         Problem: we still don't have contract-out for TR
>         So you will need to turn contracts into types and throw away
> residual contracts.
>
> One day SAM will get around to this gap.
>
> 3. Of course, you should know which entry point is best for you
> and choose for yourself at which level you wish to enter. The
> point is
>
>   with Racket, you have this choice
>
> (and with other languages, you don't.) -- Matthias
>
>
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121228/9f8f497d/attachment-0001.html>