Oh, wait: module* doesn't have the "combining" behavior of module+. Or am I misunderstanding?
I've been using the combining behavior of module+ to group tests near what they test (tests interleaved with definitions). But it seems like the only choices are: - Keep using (provide (contract-out)) but switch back to lumping all the tests together, in one module* (or even back to the old way of a separate file). - Keep using module+ but switch back to using define/contract (but that is much slower as well as being Considered Harmful). - Keep using both (provide (contract-out)) and module+, but be aware that the tests won't exercise the module-boundary contracts. Hmmm. On Tue, Mar 5, 2013 at 5:00 PM, Greg Hendershott <greghendersh...@gmail.com> wrote: > That looks great! > > On Tue, Mar 5, 2013 at 10:42 AM, Matthias Felleisen > <matth...@ccs.neu.edu> wrote: >> >> >> P.S. I have re-written chapter 3 of the style guide in particular 3.3 and >> 3.6 to add your idea: >> >> http://www.ccs.neu.edu/home/matthias/Style/style/Units_of_Code.html >> >> >> >> On Mar 5, 2013, at 9:59 AM, Matthias Felleisen wrote: >> >>> >>> 1. Clutter removal is built into Racket: >>> >>> (define-syntax (interface stx) >>> (syntax-case stx (subject-to) >>> [(interface name clauses ...) >>> ;; ==> >>> .. (provide (contract-out ..) ..) ..])) >>> >>> The above macro has become a standard in my recent projects where I place >>> it into my ./Lib/contract.rkt library. It is part of an effort to develop a >>> header-file style for Racket. And it is an effort to supply a way to >>> selectively check contracts. [More soon. It is NOT about turning contracts >>> off.] >>> >>> 2. Contract test issue acknowledged. I have run into this problem too >>> during my recent construction of a game program. My work-around >>> >>> 3. Clutter removal is built into Racket: >>> >>> #lang racket >>> >>> #lang racket >>> >>> (define-syntax-rule >>> (tmod def-or-exp ...) >>> (module* test racket >>> (require rackunit (submod "..")) >>> (check-equal? 1 1) >>> def-or-exp ...)) >>> >>> ;; ----------------------------------------- >>> >>> (provide >>> (contract-out >>> (f (-> integer? integer?)))) >>> >>> (define (f x) x) >>> >>> (tmod (check-equal? (f 2) 2) >>> (check-equal? (f 3) 2)) >>> >>> Consider adding the above module to your ./Lib/contract.rkt library. >>> >>> >>> >>> >>> >>> >>> On Mar 5, 2013, at 8:39 AM, Greg Hendershott wrote: >>> >>>> Not to flog this, but: >>>> >>>> Lately I've been trying to be a good little doobie and use `(provide >>>> (contract-out))` instead of `define/contract`. Although it's more >>>> typing/clutter, grumble grumble, I've been getting used to it. >>>> >>>> Unfortunately I discovered one gotcha: Using (module+ test <rackunit >>>> tests>) means that the test bypasses the contract -- because it's a >>>> submodule, and the contract is on the module boundary. So my unit >>>> tests weren't exercising and validating the contract. I missed a buggy >>>> contract this way. >>>> >>>> In hindsight this is all perfectly obvious. Just not from the guide. >>>> To be fair using submodules for tests is a relatively recent practice >>>> in Racket. But I wanted to point out the interaction in case it helps >>>> anyone else who is trying to use module contracts and do unit tests >>>> following the curent examples. >>>> >>>> One way to avoid this problem is instead of module+ use module*: >>>> >>>> (module* test racket ;; To test module-boundary contracts, must use >>>> ;; module* and (require (submod "..")). >>>> (require (submod "..")) >>>> ... check check check ... >>>> ) >>>> >>>> Of course this adds even more "clutter", but it works. >>>> >>>> On Thu, Dec 27, 2012 at 3:31 PM, Matthias Felleisen >>>> <matth...@ccs.neu.edu> wrote: >>>>> >>>>> I have added a note on this issue to the Style issue; see section 3.6. >>>>> Strictly speaking, this prose probably belongs into the Contract guide. >>>>> -- Matthias >>>>> >>>>> >>>>> >>>>> On Nov 30, 2012, at 5:17 PM, Ryan Culpepper wrote: >>>>> >>>>>> You can have mutually recursive functions with define/contract, but you >>>>>> can't with submodules. >>>>>> >>>>>> Ryan >>>>>> >>>>>> On 11/30/2012 05:04 PM, Ray Racine wrote: >>>>>>> Why not make this explicit by deprecating define/contract and support >>>>>>> this use case with a submodule. They lightweight enough and makes >>>>>>> boundary demarcations consistent, explicit and simple. Module -> >>>>>>> boundary. >>>>>>> >>>>>>> On Nov 30, 2012 12:05 PM, "Matthias Felleisen" <matth...@ccs.neu.edu >>>>>>> <mailto:matth...@ccs.neu.edu>> wrote: >>>>>>> >>>>>>> >>>>>>> On Nov 30, 2012, at 10:15 AM, Greg Hendershott wrote: >>>>>>> >>>>>>>>> This is a complete misunderstanding. >>>>>>>> >>>>>>>> Sometimes I feel like a kid in the room while the adults are talking. >>>>>>>> When it comes to contracts, I have to stipulate that most of you are >>>>>>>> smarter than me and have thought about this longer than me. >>>>>>> >>>>>>> >>>>>>> Apologies. My opening wasn't meant to say "I am smarter" but I wanted >>>>>>> to send a strong message about define/contract. It really introduces a >>>>>>> boundary and in some strange sense your (possibly misleading) >>>>>>> microbenchmark >>>>>>> exposes this constraint too. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ____________________ >>>>>>> Racket Users list: >>>>>>> http://lists.racket-lang.org/users >>>>>>> >>>>>>> >>>>>>> >>>>>>> ____________________ >>>>>>> Racket Users list: >>>>>>> http://lists.racket-lang.org/users >>>>>>> >>>>>> >>>>>> ____________________ >>>>>> Racket Users list: >>>>>> http://lists.racket-lang.org/users >>>>> >>>>> >>>>> ____________________ >>>>> Racket Users list: >>>>> http://lists.racket-lang.org/users >>> >>> >>> ____________________ >>> Racket Users list: >>> http://lists.racket-lang.org/users >> ____________________ Racket Users list: http://lists.racket-lang.org/users
