> 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.
Having stipulated that, it seems unfortunate and surprising that (define/contract (f x) (integer? . -> . any) x) is ~200 times slower than (define (f x) (unless (integer? x) (raise-argument-error ....)) x) It seems like "pro" Racket code avoids the former and does the latter. One reason may be that such code predates contracts, and/or old habits die hard. But another reason seems to be that the former would be unacceptably slow. I wish it weren't. Are you saying that "contract" is a fundamentally different concept than "argument checking" -- it's not a superset but some whole different beast? If so, then I guess I'm saying I want something with the declarative convenience of define/contract (or syntax-parse), but fast enough to be practical. I could refer to this other concept as "term sheets" (i.e. a light 2-page memo rather than a 100-page agreement) to avoid confusion. I've sketched that out and could just use that myself instead of disturbing you all with this feedback. On Fri, Nov 30, 2012 at 9:33 AM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > On Nov 29, 2012, at 10:29 PM, Greg Hendershott wrote: > >> AFIK these subtleties of contracts and modules arise with >> `provide/contract' -- by saying that the function should only use a >> contract outside the module (or submodule). >> >> But I prefer to use `define/contract'. For one thing, I think it's >> easier and more-maintainable to group the contract near/with its >> function in the source. But I also prefer it on the starting >> assumption that if a procedure is worth contracting at all, it's worth >> contracting all the time -- inside the module as well as outside. > > > This is a complete misunderstanding. Contracts are specifications > that govern the flow of values across boundaries. We call this boundary > a 'module' but for several years now, module and #lang have been two > distinct terms. In this spirit, > > -- #lang with provide contract-out is a module > -- define/contract is a module > -- internal modules are modules but watch out for module+ > > In contrast, > -- units and classes are values and we have contracts for them > but they do NOT establish contract boundaries, they are > NOT modules. > > In your specific case, define/contract splits an existing 'module' > into two pieces. > > ;; --- > > As I have said many times, your use of contract is likely to be > much better satisfied with the use of Typed Racket. I doubt that > many of your contracts are checking more than constructors, which > roughly corresponds to type checking. For the remaining ones, Sam > will provide > > provide/typed with contract-out > require/typed with contract-in > > ANY TIME SOON NOW. > > ;; --- > > > As for performance of contracts: > > On Nov 29, 2012, at 11:47 PM, Harry Spier wrote: > >> And then to enable/disable contracts you can use the method Mathias >> pointed out here. >> http://www.mail-archive.com/users@racket-lang.org/msg12281.html > > > Thanks for reminding the list of this post. I should write this > out as a blog post or an entry into our Contract Guide. > > > ____________________ Racket Users list: http://lists.racket-lang.org/users
