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.
smime.p7s
Description: S/MIME cryptographic signature
____________________ Racket Users list: http://lists.racket-lang.org/users
