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

On Sun, Oct 9, 2011 at 11:42 AM, Carl Eastlund <cce at ccs.neu.edu> wrote:
> 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.

If we really agreed that this was the right behavior, I think we could
probably make this work. Specifically, I'm imagining something where
the decision about who the two parties are would be made when the
variable is actually referenced and the decision would be made by
looking at the identifier and tracking the re-provide information that
the macro system exports.

I expect we'd also want to do this to avoid duplicating the wrappers.

Robby