On Sun, Oct 9, 2011 at 11:42 AM, Carl Eastlund <c...@ccs.neu.edu> wrote: > On Sun, Oct 9, 2011 at 12:30 PM, Matthias Felleisen > <matth...@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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
