<div dir="ltr"><div style>An alternate flow which I think aligns slightly better with graduated code validity vs cost (effort)?</div><div><br></div><div style>0. Quick and dirty code spikes, snippets in R.</div><div style> 1. Write prototype code directly in TR.</div><div style> - Liberal addition via Step 0 efforts, pre and current with Step 1.</div><div style> - TR is very lightweight.</div><div style> - 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.</div> <div style> - The benefits of instant TR feedback in DR while coding, IMHO, far out weight considerations of rapid prototyping without TR.</div><div style> - 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.</div> <div style>2. If you like your prototype and you know it will be around awhile:</div><div style> - Selectively transform unchecked contracts into checked contracts </div><div style> - Add contracts which increase code robustness value with consideration of performance overhead. *[1,2]</div> <div style><br></div><div style>Essentially</div><div style>Step 1: Write prototypes in statically typed code from the get go in TR.</div><div style>Step 2: Turn prototypes into high quality code by adding runtime contracts.</div> <div style><br></div><div style><div>[*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.</div> </div><div style>[*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.</div> <div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 28, 2012 at 9:42 AM, Matthias Felleisen <span dir="ltr"><<a href="mailto:matthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br> On Dec 27, 2012, at 8:58 PM, Harry Spier wrote:<br> <br> > On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen<br> > <<a href="mailto:matthias@ccs.neu.edu">matthias@ccs.neu.edu</a>> wrote:<br> >><br> >> It is critical to inform clients of the services that a module<br> >> provides. In the absence of types, contracts are the closest<br> >> information we have.<br> > AND<br> > On Fri, Dec 14, 2012 at 11:43 AM, Ray Racine <<a href="mailto:ray.racine@gmail.com">ray.racine@gmail.com</a>> wrote:<br> >> For the TR folks you can have your cake and eat it with a cup of coffee with<br> >> `provide'. TR Rules<br> ><br> > Given the above, should you be using Typed Racket instead of contracts<br> > whenever possible? Are there cases where if you have the choice you<br> > should prefer contracts instead of using Typed Racket<br> <br> <br> </div>No for several reasons:<br> <br> 1. Our contracts are actually more powerful than our types:<br> <br> see <a href="http://www.ccs.neu.edu/home/matthias/Style/style/Units_of_Code.html#(part._.Contracts)" target="_blank">http://www.ccs.neu.edu/home/matthias/Style/style/Units_of_Code.html#(part._.Contracts)</a><br> <br> especially contract for celsius->fahrenheit for an example.<br> (In principle, our type system can express this idea.)<br> <br> 2. We see Racket as a continuum:<br> -- write a script, throw it away<br> -- or grow the script/create prototype with informal contracts and data descriptions<br> -- if you like your prototype and you know it'll be around for a while,<br> turn informal contracts into checked contracts<br> weighing performance impact against importance of checks.<br> -- if you ever maintain any of these modules, split contracts into types and residual contracts.<br> Problem: we still don't have contract-out for TR<br> So you will need to turn contracts into types and throw away residual contracts.<br> <br> One day SAM will get around to this gap.<br> <br> 3. Of course, you should know which entry point is best for you<br> and choose for yourself at which level you wish to enter. The<br> point is<br> <br> with Racket, you have this choice<br> <br> (and with other languages, you don't.) -- Matthias<br> <div class="HOEnZb"><div class="h5"><br> <br> _________________________<br> Racket Developers list:<br> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br> </div></div></blockquote></div><br></div>