Will you accept patch for this, if I'll write it? (contract-out ...) will have (id debug-contract-expr production-contract-expr) instead of (id contract-expr) in syntax There will be global phase-1 variable contract-mode : (or/c 'nothing 'production 'pre 'pre-and-past 'all) = 'all
nothing -- no checks production -- use production contract if present, otherwise check only pre-condiction pre -- check only pre-condiction pre-and-post -- check pre and post conditions all -- current behavior Tue, 3 Jun 2014 12:47:18 -0400 от Matthias Felleisen <matth...@ccs.neu.edu>: > >Your mail calls for a philosophical answer. If this were Eiffel, you would be >correct. > >But Racket is not Eiffel: > -- we are not a tools company that sells a language > -- we spent our own time on a maintenance effort that goes above and beyond >our jobs > -- and we don't provide a standard language (meant to make developers happy >and its creators famous and wealthy). > >Racket is a programming language programming language [not a typo]. We wish to >go beyond conventional features. When it comes to contracts, this means we >wish to provide (1) higher-order contracts so that we cover the full spectrum >of linguistic features and (2) a programmable toolbox so that programmers can >create their own favorite idioms -- above and beyond the stuff available in >standard languages. > >We fully understand that expanding the horizons of the language puts some >burden on programmers. Every programmer may have to develop his own techniques >and tools and idioms for our new features. We balance this burden with a >catalog-driven on-line library, where programmers can register little more >than a github URL to share such libraries. > >With apologies for the extra burden and the non-technical answer -- Matthias > > > > > > > >On Jun 3, 2014, at 12:24 PM, Roman Klochkov < kalimeh...@mail.ru > wrote: > >> There should be _standard_ check-modes. With global variable (or better >> compile-mode). >> >> 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. >> Even if another developer will use the same idea, he or she will have own >> modes and own variable to set them. >> >> >> Tue, 3 Jun 2014 07:47:37 -0400 от Matthias Felleisen < matth...@ccs.neu.edu >> >: >> >> 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. >> >> >> On Jun 3, 2014, at 12:38 AM, Daniel Prager wrote: >> >>> > I propose something like two contracts: for debug and production modes. >>> >>> Eiffel compilers implement a sliding scale of contract-checking, something >>> like: >>> • Check nothing [naive] >>> • Check pre-conditions only [good for production - quick] >>> • Check pre- and post-conditions only [can be slow] >>> • Check pre- and post-conditions and invariants [van be very slow] >>> [Loop and ad hoc assertions would have been in there too.] >>> >>> Post-conditions and invariants can be *very* expensive to check, but are >>> great when debugging. >>> >>> Pre-condition checking is typically cheap, and quickly tells you when >>> trusted code is being called with bad arguments. >>> >>> 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. >>> >>> 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. >>> >>> How does the picture change with higher-order contracts and checking at >>> module boundaries? >>> >>> Dan >>> >>> >>> >>> On Tue, Jun 3, 2014 at 6:20 AM, Roman Klochkov < kalimeh...@mail.ru > wrote: >>> 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. >>> But inserting the element is O(log n) and testing will be O(n). >>> >>> option contracts -- 1) unstable 2) should be turned off and on individually. >>> >>> For quick hack, I'll simply redefine contract-out and recompile all. But I >>> propose something like two contracts: for debug and production modes. >>> >>> >>> Mon, 2 Jun 2014 15:49:05 -0400 от Matthias Felleisen < matth...@ccs.neu.edu >>> >: >>> >>> >>> On Jun 2, 2014, at 3:42 PM, Roman Klochkov < kalimeh...@mail.ru > wrote: >>> >>> > Is there a way to disable all contract checks? >>> > >>> > 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. >>> > 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? >>> >>> >>> No. >>> >>> ;; --- >>> >>> 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 >>> >>> ;; --- >>> >>> You will need to define a version of provide and/or contract-out that >>> throws away contracts based on a switch. >>> >>> Or you check out option contracts and use those. >>> >>> -- Matthias >>> >>> >>> >>> -- >>> Roman Klochkov >>> >>> ____________________ >>> Racket Users list: >>> http://lists.racket-lang.org/users >>> >>> >>> >>> >>> -- >>> Daniel Prager >>> Agile/Lean Coaching, Software Development and Leadership >>> Startup: www.youpatch.com >>> Twitter: @agilejitsu >>> Blog: agile-jitsu.blogspot.com >> >> >> >> -- >> Roman Klochkov > -- Roman Klochkov
____________________ Racket Users list: http://lists.racket-lang.org/users
