<HTML><BODY>There should be _standard_ check-modes. With global variable (or better compile-mode).<br><br>Because, I can in my own libraries make this 4 or even more modes. But I use 3d-party or standard library. And I cannot rewrite them all to my 4 modes. <br>Even if another developer will use the same idea, he or she will have own modes and own variable to set them.<br><br><br>Tue, 3 Jun 2014 07:47:37 -0400 от Matthias Felleisen <matthias@ccs.neu.edu>:<br>
<blockquote style="margin: 10px; padding: 0px 0px 0px 10px; border-left-color: rgb(8, 87, 166); border-left-width: 1px; border-left-style: solid;">
        <div>
        



    









        
        


        
        
        
        
        

        
        

        
        



<div class="js-helper js-readmsg-msg">
        <style type="text/css"></style>
        <div>
                <base href="https://e.mail.ru/" target="_self">
                
                        <div id="style_14017960680000000482_BODY"><div><br></div><div>You can program these scenarios with option contracts; see comparison in paper. Perhaps it's time to write this up as a chapter for the Guide. </div><div><br></div><br><div><div>On Jun 3, 2014, at 12:38 AM, Daniel Prager wrote:</div><br><blockquote type="cite"><div dir="ltr"><div>> I propose something like two contracts: for debug and production modes.</div><div><br></div><div>Eiffel compilers implement a sliding scale of contract-checking, something like:</div>
<ol><li>Check nothing [naive]</li><li>Check pre-conditions only [good for production - quick]</li><li>Check pre- and post-conditions only [can be slow]</li><li>Check pre- and post-conditions and invariants [van be very slow]</li>

</ol><div>[Loop and ad hoc assertions would have been in there too.]</div>
<div><br></div><div>Post-conditions and invariants can be *very* expensive to check, but are great when debugging.</div><div><br></div><div>Pre-condition checking is typically cheap, and quickly tells you when trusted code is being called with bad arguments.</div>

<div><br></div><div>Recommeneded development practice was to start with all contracts checked, and as one's code iterated towards trustworthiness turn down the checking-level (but leave pre-conduitions on) and enjoy the huge speed boost. </div>

<div><br></div><div>There's value in being able to control checking on a per module basis, essentially doing deep checks on newer / less-tested / less-trusted parts of the system.</div><div><br></div><div>How does the picture change with higher-order contracts and checking at module boundaries?</div>

<div><br></div><div>Dan</div><div><br></div></div><div><br><br><div>On Tue, Jun 3, 2014 at 6:20 AM, Roman Klochkov <span dir="ltr"><<a href="//e.mail.ru/compose/?mailto=mailto%3akalimehtar@mail.ru" target="_blank">kalimehtar@mail.ru</a>></span> wrote:<br>

<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div>The problem is that, when debbugging, contract should be precise. For example, insert-in-sorted-queue may check that queue is orted before and after the function. <br>But inserting the element is O(log n) and testing will be O(n).<br>

<br>option contracts -- 1) unstable 2) should be turned off and on individually.<br><br>For quick hack, I'll simply redefine contract-out and recompile all. But I propose something like two contracts: for debug and production modes. <br>

<br><br>Mon, 2 Jun 2014 15:49:05 -0400 от Matthias Felleisen <<a href="//e.mail.ru/compose/?mailto=mailto%3amatthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>>:<div><div><br>
<blockquote style="margin: 10px; padding: 0px 0px 0px 10px; border-left-color: rgb(8, 87, 166); border-left-width: 1px; border-left-style: solid;">
        <div>
        



    









        
        


        
        
        
        
        

        
        

        
        



<div>
        
        <div>
                
                
                        <div><br>
On Jun 2, 2014, at 3:42 PM, Roman Klochkov <<a href="https://e.mail.ru/compose?To=kalimehtar@mail.ru" target="_blank">kalimehtar@mail.ru</a>> wrote:<br>
<br>
> Is there a way to disable all contract checks? <br>
> <br>
> Suppose, I debugged my program and sure that it is reliable. I disable debugging, but as I understand, contracts are still checked in every function.<br>
> But I want to maximize the performance of my program. Is there a way to do that or I have to manually hack racket/contract/base to do that?<br>
<br>
<br>
No. <br>
<br>
;; --- <br>
<br>
Programmers who disable assertion checking as they are deploying software are like people who wear life vests on land when they learn about the theory of sailing and take them off as soon as they board the boat for practical exercises on the water. -- somebody famous <br>


<br>
;; --- <br>
<br>
You will need to define a version of provide and/or contract-out that throws away contracts based on a switch. <br>
<br>
Or you check out option contracts and use those. <br>
<br>
-- Matthias<br>
<br>
</div>
                        
                
                
        </div>

        
</div>


</div>
</blockquote>
<br>
<br></div></div><span><font color="#888888">-- <br>Roman Klochkov<br></font></span></div>
<br>____________________<br>
  Racket Users list:<br>
  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div style="font-family: arial; font-size: small;"><b>Daniel Prager</b></div><div style="font-family: arial; font-size: small;">Agile/Lean Coaching, Software Development and Leadership<br>

</div><div style="font-family: arial; font-size: small;"><font color="#999999">Startup: </font><font color="#000000"><a href="http://www.youpatch.com/" target="_blank">www.youpatch.com</a></font><br data-mce-bogus="1"></div><div style="font-family: arial; font-size: small;">

<font color="#999999">Twitter:</font> <a style="color: rgb(17, 85, 204);" href="https://twitter.com/agilejitsu" target="_blank">@agilejitsu</a> </div><div style="font-family: arial; font-size: small;"><font color="#999999">Blog:</font> <a style="color: rgb(17, 85, 204);" href="http://agile-jitsu.blogspot.com/" target="_blank">agile-jitsu.blogspot.com</a><br data-mce-bogus="1"></div>

</div>
</div>
</blockquote></div><br>
</div>
                        
                
                <base href="https://e.mail.ru/" target="_self">
        </div>

        
</div>


</div>
</blockquote>
<br>
<br>-- <br>Roman Klochkov<br></BODY></HTML>