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. >> 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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
