[racket] Making a contract between a function and "the world in general"

On Sun, Oct 9, 2011 at 12:30 PM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> On Oct 8, 2011, at 9:49 PM, Ryan Culpepper wrote:
>
>> But in your alternative,
>>
>>  (provide (contract-out [f contract-of-f]))
>>
>> the contract of f is *still* not manifest in the module. Instead of chasing down f, we have to chase down contract-of-f. We've
>> also duplicated code/knowledge (the association between f and contract-of-f) with all the problems that entails. Also, we've
>> cluttered up the namespace with these contract-of-* bindings.
>
> Perhaps you are right. Perhaps we should go even further and every 're-provide' should implicitly propagate contracts.

We have to be careful with this.  There are places where we rely on
the fact that requiring the same binding from two places into the same
scope does not create a name conflict.  If implicitly propagating
contracts involves creating a new binding, duplicate imports with
contracts would suddenly break.

>> Of course, duplicating the contract expression would make it manifest, but it would aggravate the ill effects from code
>> duplication. My experience: partly because of its lazy-require tricks, the db library has some duplication of contracts, and I
>> hate it. I've also eliminated internal contracts to avoid having to repeat them in the externally-visible modules.
>
> I consider that last part *good*. So perhaps it did push you in the right direction.

I'm confused, which part is good?

--Carl